Press enter to see results or esc to cancel.

Blue-Green Deployment Explained

What is blue-green deployment?

Blue-green deployment is an application deployment strategy that aims to ensure uninterrupted uptime for the users when shifting between versions. This can be a rollout of a new application version or a rollback after detecting bugs.

How blue-green deployment works?

A blue-green deployment consists of two identical production environments: a green environment that hosts the old version, and a blue environment that hosts the new version. Initially, all traffic continues being routed to the green environment as the blue environment is being tested. After the tests are complete, traffic is directed to the blue environment and the blue environment is kept on standby in case there is a need for a rollback.

The word environment, in this case, represents everything you need to run your application. This includes servers, containers, operating systems, virtual machines, and anything else that might be needed. The environments can be two virtual machines on the same hardware, two physical machines, or different containers on the same device.

In cloud deployment, you can use CI\CD tools to create an identical environment. With Wildcard’s  CI/CD tools you can create an identical environment in minutes. Try it for free here!

Pros and cons of blue-green deployment

One of the main benefits of this deployment strategy is the ability to test your application in an environment that is identical to the production environment. This means that you are able to identify bugs and fix them before the users start interacting with the application. Another benefit is that you can gain enough data from the tests done in the production environment to predict the stability of the new application version.

One of the main challenges with this strategy is the fact that it is resource-intensive. Creating an identical environment can be resource-intensive due to the acquisition and labor costs. Another challenge that comes with it is the complexity associated with data handling during the migration. We’ll discuss this in another section of the article.

How traffic is handled?

Blue-green deployment relies on a mechanism that can change traffic destinations from the green environment to the blue environment. This can be a router, reverse proxy, load balancer, or web server. You have the option of gradual or instant transfer of traffic from green to blue. When traffic is directed to the new environment using an instant cutover method, users see a new application instantly without any latency.

How the database is handled?

Handling the database during a blue-green deployment is a challenge that sometimes requires complex schema change to resolve. The reason why this is a challenge is that you are moving the application but keeping the database. Therefore, it has to work with both the old application version and the new application version. Unfortunately, this is not always the case because the new version might be handling the data in a different way (e.g. different schemas between versions).

One of the ways to achieve seamless migration is to alter the schema to support both versions of the application. This can be done using additive schema modification which involves adding fields, entries, and any other important aspect. Once you configure the schema to support both versions you then implement database migration before application migration.

The second method of handling the database is to modify the schema after a deployment. This is done using deletive schema modification which involves deleting, merging, or consolidating the unneeded fields. This is possible because the old application has been decommissioned and it no longer needs to use the database.

With the first method, we configure forward compatibility and with the second method, we configure backward compatibility. In some cases, decoupling schema and code changes can result in complex implementations that lead to data loss. Be careful when altering the schema and keep a record of the changes to ensure that you can reverse it in case of a mistake.

Best use Case

This strategy requires a lot of resources to set up and is therefore not cost-efficient with frequent updates. However, it is very effective in the continuous deployment of applications with major updates.

For instance, a payment platform that has a new version with an updated  UI, new payment APIs, and a new chatbot feature is best deployed using the blue-green deployment. This is because the system has sensitive features that require robust testing to verify the functionality of both the user interface and the security of the system. It would not be prudent to test payment systems on a section of users because bugs can lead to loss of revenue or expose the system to attackers.

In this case, the database would require additive schema modification to ensure that new data fields work with the new version.

Summary

Blue-green deployment is a strategy that allows for migration from an old application version to a new version with zero downtime. It works by creating two production environments, blue and green, that run parallel to each other. For the deployment to be considered complete all the traffic has to be shifted from the green environment to the blue environment. The biggest benefit of this strategy is allowing for rigorous testing of a new version in a production environment before traffic is directed to it. The challenge of database handling during migration can be solved by using either the forward compatibility method or the backward compatibility method.

Create a CI/CD pipeline with Wildcard

You don’t have to be a DevOps engineer to start creating CI/CD pipelines. We provide a platform that gets you started with continuous deployment without writing any code. Check it out and start creating your CI/CD pipeline in minutes!

Share this article