In our previous series of blog posts, we discussed what is Liquibase and how we can leverage Liquibase to manage database changes and associated functionality. We have seen and discussed various commands and attributes available. However we have not discussed putting everything together and creating a multi stage pipeline using some sort of CI/CD tool like Azure DevOps, Jenkins, TeamCity etc. The focus of this blog post will be to create a multi stage yaml pipeline for deploying database changes using Maven, Liquibase and Azure DevOps. The target environment will be Azure PostgreSQL for this post’s purposes, but it can be any target database in accordance with your needs.
Continue reading “Create Multi Stage YAML CI/CD pipeline for deploying database changes using Maven, Liquibase and Azure DevOps”
In the last few posts on the managing database changes, we discussed how it is useful and what are the various benefits available. One of the core philosophies of the Database as a Source Code involves treating code for Database changes as source code. This is not limited to using a version control system like Git / Subversion / Mercury etc. but it also expands to other areas like designing the proper directory structure, making it scale ready for future changes, minimizing merge conflicts etc. In this blog post, we are going to discuss some of the practices used for organizing database changes when using Liquibase.
Continue reading “Version Control Practices for Managing Database Changes for Liquibase”
In our previous blog post, we describe how we can conditionally prepare for database state to determine certain conditions and then only proceed to deploy our changes. This prevents us from doing errors like inserting the same record again or dropping a table full of records. However, irrespective of our precautionary measures, mistakes are bound to happen. So we need to prepare for those eventualities as well. This may also be needed if you roll out certain changes and found that those changes were inadequate to resolve the matter at hand. In liquibase, we can prepare for these kind of scenarios using the concept of rollback and tags.
Continue reading “Prepare failback strategy for database changes with Liquibase”
In our previous blog post, we discussed how we can apply different changelogs to different database environments. It is more than often, that when applying a changelog, changeset writer assumes database in a certain state. Like when you are adding a column to the database, you would assume that corresponding table is present. Or when you are dropping a table, it has no data in it. Or we assume that underlying database connection is of a particular nature. We can check for and decide what to do by using the concept of Preconditions in the Liquibase. Using preconditions allows to validate underlying assumption and decide the course of action. Continue reading “Check database state and conditionally apply changes in the Liquibase”
In our previous post, we learned how to use Liquibase to export and compare databases. That brings us to another important question: how do we deploy separate changes on separate database environments like dev, qa, prod etc. Often times, developers would want to push certain changes in the dev environment more frequently and often and not all of them necessarily make it into the production. For example, dev database may have a special ERRORLOG table which stores the debugging information, but there is no requirement of that in the QA or production environment. Similarly, QA team would like to insert some data and modify certain values Continue reading “Selectively apply Changes to Database Environments using Liquibase”