Blue-green deployments strategy

Recently, I've written about the database schema migration tool we adopted for our project. Having a proper tool set is essential, but it is much more important to choose the right strategy for database schema migration so that the next application update does not turn into a nightmare and financial loss.

Blue-green deployments strategy is my favorite. It is widely used to deploy new code in application contexts, and it can be used for database schema changes to a certain extent, but does have some notable shortcomings.

Blue-green deployments is an approach that involves setting up two identical or near to identical sets of infrastructure for your database clients. Together, they require twice as many resources to run the production traffic. Although it can be expensive financially, if used properly, this strategy can keep complex systems running without downtime.

The current production traffic is served by a first of Blue set of infrastructure. The next application release is configured using the second of the Green set of infrastructure. When everything is prepared and tested, the load balancer or another traffic director routing client switches traffic from the first set to the second set to introduce the new changes.

If a problem arises the traffic can be switched back to the original infrastructure. If everything goes according to plan, the first infrastructure set will be used to stage the upcoming deployment.

The appeal of blue-green deployments is that they let you make changes to production-ready infrastructure without affecting the live production environment. Developers can test changes on the infrastructure where they will actually run without interruption by decoupling the deployment process from the “release” of the change.

You can easily undo changes by releasing new code and modifications using a switch mechanism.

While blue-green deployments strategy is useful in many scenarios, applying it with schema changes requires attention to possible incompatibilities. When only application code is changed without impacting the current database schema, reverting problematic code is as simple as redirecting traffic back to the original set of infrastructure. But incompatibility is possible when the data schema changes. Reverting to the previous infrastructure may result in data loss, as when the table fields are removed, etc.

We strictly follow the rules adopted in our company, such as the atomization of changes. And in general, with good test coverage, this strategy produces excellent results even in case of significant changes in the database schema. We use the “expand and contract pattern” to organize our deployments when using blue-green deployments with schema changes to help us avoid these problems.

The expand and contract pattern is a technique for making new changes to a database schema without having an impact on already-running programs.

It functions by introducing changes in small, controlled increments by first integrating new or modified structures alongside existing structures, then extending the application logic to utilize both structures concurrently. After testing, the application can eventually stop writing to the original structure and be removed.