How to Get Your Local Environment Up and Running Fast and Start Your Day Right
Developers need all the tools they can get to make their lives easier. In-memory embedded databases and database migration tools should be a must-have in every developer’s toolbox. This because they ensure quick startup, development, and deployment processes.
As a software architect at Quantyca, an Italian IT consulting firm, one of my tasks is choosing the right tools and techniques to make our developers’ day to day work easier.
Applications (almost) always involve some kind of data storage. We must meet this need while keeping the application development fast and efficient.
In this blog post, I will show how you can deal with databases in your application and in particular I will discuss:
- about all the problems that you will face if you don’t use a local development environment or if you don’t choose the right tools to manage it;
- how you can take advantage of embedded databases to speed up the startup routine;
- how to reliably distribute the development environment and to quicken the development process with database migration tools.
All the things that make you wake up on the wrong side of the bed
There are a lot of things that prevent us as developers to start our everyday work flawlessly.
First of all, the fact that everyone in our team shares the same development database. This is frustrating because when one of us needs to alter the schema the shared database will appear all messed up for the others.
Moreover, as every developer knows, it is essential to run tests. In particular, integration tests are vital. So, during daily development, everyone needs to write and try some tests that actually hit external databases. But are we sure that we can rely upon external systems for our everyday work? The answer should be no.
Thus, everyone will agree with the absolute need for a local environment.
But, given this choice, we are exposed to a poorly designed environment.
In the first place, virtual machines can be a tempting option for installing the local database. Mostly because you can share them among all team members. But their set up is not so simple and they also add to your project another piece that must be maintained. Also, developers have to boot virtual machines every morning alongside their IDE and maybe some other development tools.
In a situation of distributed development environments, the propagation of database schema changes is an important attention point. If you don’t automatically manage schema updates, you could end up with annoying environment breakages.
Below I present you the tools that my colleagues and I use to set up a practical local environment. It helps us to speed up the environment start and our development and deployment processes.
Let’s exploit the power of embedded DBs
The most important tool to take into account in order to achieve some speed is an in-memory embedded database. Indeed, embedded databases guarantee a one-click startup process of our application. Furthermore, when a new developer joins the team we won’t need to lengthy instruct her on how to set up the local environment. It will be enough for her to clone the project repository, import it in the preferred IDE and run the application.
Also, embedded DBs remove dependence on the network. This implies that developers can run tests under every circumstance.
We picked H2 as our embedded database of choice. H2 is open source, is purely written in Java, is very fast and has a small footprint. Also, H2 is supported by Spring Boot. So we can easily benefit from auto-configuration: we only need to include a dependency and the database will be available for use.
Obviously, in-memory databases don’t provide persistent storage and you need to populate your database when your application starts. Spring Boot is a powerful framework and it’s able to help you set up the database’s tables and populate them. By default, if Spring Boot detects that you are using an embedded database, it looks at the entities in your code and creates the tables. You can also populate some data by adding a file called data.sql and Spring Boot will execute every query in that file as part of its startup routine.
Let’s recap some pros and cons of using embedded DBs.
👍 Embedded databases enable a one-click startup process — it’s as easy as open your IDE and run the application.
👍 With embedded DBs, set up and share the development environment is simple.
👍 Embedded databases ensure you don’t have to connect to a remote server over the net, so you can always execute tests.
👎 Database engines all behave a little bit different, thus compatibility issues can arise among local and production databases.
Stay safe with a DB migration tool
Database migration tools help you a lot speeding the development process because they allow for easily and trustfully adapting schema as the project requirements change over time.
In practice, many schema migration tools rely on a textual representation of schema changes (such as files containing SQL statements). In this way, the history of schema changes can effectively be stored alongside program source code within a versioning control system.
This implies a lot of benefits. First of all, this approach guarantee that the schema definition updates alike in all developers’ local environment and in every other environment in which our application is deployed; so the version of database schema against which the code was developed and with which the code is fully compatible is automatically aligned everywhere. Besides, the handling of concurrent conflicting schema changes is straightforward and developers may simply use their IDE to reconcile differences. At last, schema migrations ensure that the information necessary to roll back to a working version of the database schema is always recoverable from the VCS source tree.
Some popular frameworks added database migration as part of their offering. With Spring Boot you can choose among the two supported tools: Flyway and Liquibase. We chose the former and, as usual, thanks to Spring Boot’s auto-configuration we just had to provide the dependency and we were ready to code. You can even add Flyway in midway through your development cycle in a simple manner.
To make a long story short, here you find the greatest advantages and disadvantages of database migration tools.
👍 Schema migration tools add versioning capabilities to databases.
👍 Migration tools prevent schema mismatch when working with multiple environments. They ensure that software releases are always delivered with the matching state of the database.
👎 It is not easy to change a migration after it has been checked.
👎 Not all databases and versions are supported out of the box.
Final thoughts
To sum up, embedded databases enable a one-click startup of our local environment while schema migration tools prevent schema mismatch among the distributed local environments. So they can incredibly improve developers’ everyday work. Just be aware of compatibility issues.
How do you set up your local environment? What do you think about our solution? Let me know if you found our advice useful or if you had any suggestions on how to improve our toolbox.
Useful links
The best place to learn in details how H2 and Flyway work and how they integrate with Spring Boot is from the docs.
