Easy Blue-Green Deployments with Liquibase
Every release manager’s dream is to easily achieve continuous delivery with zero downtime. Blue-green deployments are a popular technique teams use to make it a reality.
What is a blue-green deployment?
A blue-green deployment uses two production environments (known as Blue and Green) to provide reliable testing, continuous no-outage releases, and instant rollbacks.
At any given time, only one of the production environments is live. The Blue environment, for example, receives all user traffic while the clone (Green) remains idle. When a new version of the application is ready for release, it is deployed to the Green environment for testing. Once the release passes testing, the application traffic is routed from Blue to Green. The Green environment becomes the new production environment, and the Blue goes idle.
Databases add complexity
In its purest form, blue-green deployments expect every application resource to be duplicated. However, it doesn’t make sense to run two copies of the database. Users would be adding and updating records on both the blue and green databases requiring a complex data synchronization process. For that reason, blue-green deployments typically share a database.
The shared database presents a challenge: two versions of the application code must be running at the same time, communicating with the same database.
There are two requirements for implementing blue-green deployments using a shared database:
- Make all database changes backward compatible.
Any changes made to the database schema must not break the existing application. There are many techniques for making database changes backward compatible.
- Decouple database changes from application changes.
Since all database changes are backward compatible, they do not have to be deployed at the same time as the application changes. The database changes can be made ahead of time so that the database can serve either Blue or Green environments.
Solving the database issue with Liquibase
Deploying changes to the shared database requires a coordinated and gradual approach. The database state is migrated with many small steps to the new state without any downtime. This process requires a level of precision and control that is difficult to achieve by manually deploying scripts.
By using Liquibase, you can precisely track and control the database changes deployed to each environment. If we want to change the schema, we create a new SQL script and add it to the Liquibase changelog. Then the CI/CD automation process can run Liquibase to deploy the changes without manual intervention.
Let’s look at a specific example. We want to rename a column from
ZIP_CODE to POSTAL_CODE to accommodate our international customers. Assume that “Blue” is currently online.
- DB Change 1: Use Liquibase to deploy a script to add the column
- App Change 1: Update Green with an application version that reads
ZIP_CODEand writes to both
- Router Change 1: Green goes online.
- DB Change 2: Use Liquibase to deploy a script to transfer all values from
- App Change 2: Update Blue with an application version that reads and writes only the new column
- Router Change 2: Blue goes online. Now only the new column POSTAL_CODE is used.
- DB Change 3: Use Liquibase to deploy a script to remove the old column
ZIP_CODEfrom the table.
As you can see, implementing a blue-green release process requires precise control and coordination of database and application releases. It also requires the right alignment of architecture, infrastructure, and tooling. Liquibase provides the precision and control to automate database changes throughout the blue-green release cycle.
Best way to get started with blue-green deployments
Process changes are often disruptive. Since the database layer can be the most challenging part of blue-green deployments, consider making process changes in smaller steps. You can start with the goal of minimizing downtime. For example, create a pre-migration changelog. This changelog contains database migration scripts that can be run online before the maintenance window. The purpose is to reduce the amount of offline time. New objects like tables, indexes, and views are good candidates to be created early. Next, add a post-migration changelog. Over time, all changes will be performed in the pre- and post-migration phases eliminating the need for a downtime window.
Summing it up
Implementing a blue-green release approach has many advantages including:
- No downtime
- Reduced risk
- Instant rollback
However, blue-green releases require a coordinated, incremental approach to database change which can only be achieved through a managed and automated database release process and that’s where Liquibase can help in multiple ways. Liquibase is designed to help your team automate database schema changes and also enable and support your team to update processes so that you can code at full speed and continuously deliver with full confidence. Contact us and let us know how we can help your team get started.
Automate BigQuery schema change and version control with database DevOps
Google's BigQuery is a fully managed, serverless cloud data warehouse, or database as a service (DBaaS), that brings unparalleled scalability and convenience to data analytics.