Steve, software development today is characterised by agile processes – meaning short development cycles, fast releases, continuous delivery and integration. Is this really also presenting database schemas and database changes with new challenges? And if so, which ones?
In the agile approach, particularly through the YAGNI principle (“You Aren‘t Gonna Need It”), database schemata are also evolving iteratively and require frequent changes and adjustments.
Continuous integration means that all changes are tested automatically. Special CI systems are used which automatically build and test the latest development status. If the database schema changes, this means that the CI system has to be aware of it – and, in the best case, automated.
In the case of continuous deployment/delivery, this is even more important since automation extends all the way to the productive system. If the database is not properly updated here, it can result in failure. The peculiarities of the CD also need to be noted. Several versions of the software usually run in parallel for some time, as the new version is distributed on a rolling basis to avoid downtime. Developers need to pay attention to compatibility in such cases.
So it’s a question of automation. Can you briefly explain what Liquibase is and what advantages it has in this environment?
Liquibase allows developers to write automatic migration scripts for databases. Liquibase ensures that scripts are executed only once and that they do not change again. The update scripts are then also included in the version and are thus also available to the CI/CD system. This will allow the CI system to test new scripts with the previous software release to ensure compatibility.
Does this affect overall quality of the delivered software and/or efficiency of the development process?
The automation of schema updates is definitely an efficiency gain. The developer does not need to contact any database to update it. This also prevents a database or instruction from being overlooked. This often leads to slowly drifting database statuses – and developers can ultimately no longer be sure that their development status is still suitable for the production database.
What about the performance of database queries when Liquibase is in use?
Liquibase does not change the performance itself. Versioning, however, makes it possible to continually adapt the schemas to growing requirements – e.g. by new indices, views and the like – or to restructure data structures.
Are there specific industries or fields of application where the use of Liquibase is particularly recommended?
Liquibase is a tool that can be used anywhere – especially if the developer does not have, or should have, direct access to the productive database. This not only applies to server software such as web applications, but also to desktop software with its own database.
What advice would you give to developers who want to integrate Liquibase for the first time?
Think about how you want to integrate Liquibase – either as part of a separate update routine or integrated into the application launch. Both have advantages and disadvantages.
Make sure Liquibase writes relative paths to its changelog. Background – Liquibase remembers the script name incl. the path. If the path changes, the scripts are considered new and executed.
What recommendations do you give to customers who are deciding for or against using Liquibase?
Schema versioning really has no disadvantages. Since the technology stack is only minimally increased by Liquibase, the time to invest is relatively low – but the benefits are enormous.
Flyway is another popular choice, besides Liquibase. Although both can basically do the same thing, they have slightly different approaches (e.g., semantic versioning vs. changesets), assumptions, and licensing models. Here, you should check whether the tool is suitable for your own process and whether you need a commercial variant. The open source variant is usually sufficient to get started.
Thanks for this conversation, Steve.