Liquibase in the Enterprise: Part 1
One of the best software development tools I have used in recent years is Liquibase, a database change management tool sometimes referred to as a database refactoring tool, although I much prefer the former definition since use of Liquibase is not contrained to refactoring (growth of a database schema is not necessarily equivalent to restructuring).
While the Liquibase website states its premise as "all database changes are stored in a human readable yet trackable form and checked into source control", it is the former which Liquibase actually performs rather than the latter, although as we will see in this discussion series use of Liquibase is just one part of the overall database change management process.
Liquibase is open source LGPL (Lesser General Public License) software. Remember that "free software" is a matter of liberty, not price. A recent client of mine habitually referred to open source software as "freeware", and although they eventually understood the benefits of open source software and decided to go with my recommendations to incorporate such software into the enterprise, it seems appropriate from my experience to reiterate the four essential freedoms of open source:
Freedom 0 – The freedom to run the program, for any purpose.
Freedom 1 – The freedom to study how the program works, and change it to make it do what you wish. (Access to the source code is a precondition for this.)
Freedom 2 – The freedom to redistribute copies so you can help your neighbor.
Freedom 3 – The freedom to distribute copies of your modified versions to others. By doing this you can give the whole community a chance to benefit from your changes. (Access to the source code is a precondition for this.)
The focus of this discussion series is every day usage of the tool. By introducing Liquibase into the enterprise at a recent client and using it for database change management over the course of a calendar year for the new enterprise database, as enterprise data architect several core benefits became increasingly evident.
Decreased cost. Use of Liquibase in the database change management process automates much of the work that is typically required of the database administrator and data architecture team. In addition to automation, the recording of database changes over time enables the reversion back to previous database states corresponding to previous software states.
Increased maintainability. Liquibase simplifies change management across multiple database instances, especially when such instances hold different versions of the same database schema to support multiple development teams. In addition, Liquibase stores version information and what SQL has been applied to support the given database schema version right in the database itself, eliminating the confusion and/or delayed discovery that can result when development teams need quick access to version metadata.
Effective incorporation into the software build process. While not a requirement to adopt Liquibase, the tool enables automated migration of database schemas to support domain object changes when following an agile software development process, negating the requirement to manually apply changes and shielding development teams from the need to understand DDL since in this world of object-relational mapping (ORM) many software developers are simply more accustomed to the object world.
Any enterprise architect needs to weigh the pros and cons behind the various options available to them, and although the pros listed above are significant, one needs to understand the cons up-front. From my experience, the only significant drawback that needs to be mentioned is the fact that Liquibase does not provide database change management for application data itself.
While reference (sometimes referred to as "lookup") data can be managed quite well, the architect needs to be aware that Liquibase was not intended to support management of application data (i.e. data which is updated by software applications that use it).
Commercial tools are of course available, but a simple solution might be to back up data prior to each database schema migration in lieu of such software. The drawback here is that once a given database schema becomes sizeable, the backup process becomes less trivial, although most database scheme changes tend to occur during the initial stages of a software development effort.
In the next part of this discussion, I will start providing an overview of Liquibase. Subsequent discussions will cover some of the gotchyas when using the tool, and how Liquibase fits into the overall database change management process as part of an agile software development effort.
Liquibase in the Enterprise: Part 2
Liquibase in the Enterprise: Part 3
Liquibase in the Enterprise: Part 4
Liquibase in the Enterprise: Part 5