What is blue-green deployment?

One environment is live and serves users, labeled “blue” and another, the “green” environment, is used for the deployment and testing of a new version. When the new version is approved, traffic is instantly routed from the blue environment to the green environment.

The strategy was popularized and named by Jez Humble and David Farley in their seminal 2010 book Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.

Blue-green is a continuous deployment technique that allows for the elimination of downtime, the ability to instantly issue rollbacks to an old version. It provides for easy A/B testing and creates a safe environment for development without the risk of end users stumbling upon a version that’s not ready.

While the “blue-green” phrasing is most common, there are variations. Netflix uses “red/black,” but the concept remains the same. Sometimes, developers might want to have more than two environments. The color naming scheme is effective for differentiating between two environments. However, organizations might also use naming conventions like version numbers, build IDs or customized titles, especially if there are more than two environments involved.

While simple in concept, there are several steps and variables within those steps to create a stable, safe blue-green deployment that takes advantage of the strategy’s benefits.

Creating identical environments for blue-green deployment can be accomplished either manually or by using automated tools. Infrastructure as Code, or IaC, is one automated approach to provisioning. IaC uses machine-readable configuration files, a bit like a set of instructions or a recipe to enable the automatic provisioning and configuration of IT infrastructure according to predefined specifications.

IaC enables developers to automatically spin up a copy of the blue environment, which is already operational, for use as the green environment. Developers can then edit these templates as needed, knowing that they’re starting from a trustworthy place. Using IaC helps ensure repeatable, precise replication.

Containerization, in which application code, dependencies and APIs are all packaged together into one “container image,” is another approach. Using containers guarantees that the entire environment is identical. Kubernetes, an open source container orchestration platform, is commonly used for containerization in blue-green deployment.

After the environments are created, the application is deployed to the blue (live) environment.

A load balancer is a mechanism, often found in front of application environments as a tool within cloud providers or Kubernetes environments, which directs production traffic as wanted. In this scenario, the load balancer directs traffic to the live, blue environment.

Then, the new code with the application updates is deployed to the green production environment. Because the load balancer is routing traffic to the blue production environment, the green is a safe space to experiment, test and configure. 

When the deployment process to the green environment is complete, conduct all necessary validation steps. These steps might include security scans, performance checks, bug scans and more.

When the green environment is validated and approved by all necessary stakeholders, update the load balancer to direct traffic from the blue previous version to the green new version.

This cutover will be instantaneous; users will not at any point see an error or something other than the blue or green environments.

DNS updates can be used to direct users to the wanted environment, but there can be significant delays as caches refresh the IP address. Due to these concerns, load balancers are preferred because the updates take effect immediately.

While the validation step should have picked up on most potential bugs or performance issues, it’s still important to monitor the green newly live environment. Analytics software and services can help here. Comparing activity can indicate whether something unusual is going on.

If something does go wrong, user traffic can be redirected to the blue environment while developers troubleshoot the issue.

Decommissioning a disused blue environment is optional; some organizations might want to keep the blue environment indefinitely in case the green environment needs to be rolled back at some point. But there are also potential cost reasons to decommission blue environment at some point in its lifecycle. Alternately, the blue environment can become the next experimental, or green, environment.

The continuous integration/continuous delivery pipeline is “an automated DevOps workflow that streamlines the software delivery process.” This pipeline facilitates the continuous delivery of code changes in applications.

It is a practice closely integrated with blue-green deployment: CI/CD enables blue-green deployment and blue-green deployments are often built into CI/CD pipelines to help release software updates with zero downtime and reduced risk.

CI pipelines automatically test and integrate new code before it is integrated into the central repository, reducing the risk of flawed code reaching deployment. CD pipelines leverage a blue-green deployment strategy to optimize rapid releases without affecting users. Blue-green deployment provides near continuous availability, and safe rollback, which plays a large role in achieving the overarching CI/CD goal of frequent, reliable code releases.

Derived from the idiom of the canary in the coal mine, canary deployments are another way to reduce risk when deploying new software versions.

While blue/green deployments create two separate environments, each of which typically either hosts all or none of the traffic, canary takes a different approach. Canary releases have only one environment, hosting multiple versions.

In a canary deployment, new versions are released first to a small percentage of users. Then, developers can see whether errors increase, performance declines or other issues arise. That small percentage of users acts as the “canary in the coal mine.” If there are no issues, traffic to the new version is steadily increased, checking for errors all the while.

The major advantage of a canary deployment over blue/green is in the infrastructure cost, as canary deployment uses only one environment to blue/green deployments two. But canary deployments can also be more complex and higher risk if a rollback is needed, compared with the simple load balancing redirection of blue/green.

The canary deployment method can be useful if potential errors are not as significant a concern as getting a new release in front of users as quickly as possible, or if developers want to monitor impact with real user experience feedback.

That said, there’s also a hybrid approach. Load balancers can direct some user traffic, say 1%, to the green environment while leaving 99% going to Blue. This effectively blends both strategies, providing canary deployment insights with the ability to quickly and easily issue rollbacks.

Blue-green deployment offers many advantages, whether used in an all-or-nothing or a canary-type rollout.

Because the load balancer switches traffic instantaneously to the wanted environment, end users never experience downtime. This is a major benefit for high-traffic instances where downtime can produce significant business problems.

Having two separate environments, one of which is known to be safe and operational, enables developers to instantly undo any changes if problems arise. If the green environment presents issues, traffic can simply be redirected to the blue environment.

Having two separate environments simplifies analysis of metrics, analytics and A/B testing for the different versions. Analytics and monitoring data can clearly be connected to either the blue or green environment, enabling straightforward comparison and health checks. This contrasts with canary deployment, which can be harder to distinguish, as both versions are active simultaneously.

A green, experimental environment enables the thorough testing of new versions out of sight of the end user. New versions are rolled out with a significant degree of confidence that they will operate as intended. In instances where this is not the case, traffic can be instantly rerouted back to the stable blue environment.

While blue-green deployment offers many benefits, there are potential drawbacks and non-optimal use cases that development teams should consider.

With two fully provisioned environments running, hosting and infrastructure costs can increase. It’s not necessarily the case that these costs will be precisely double the cost of a single environment. In some cases, the green environment will run a smaller footprint or the blue environment might be quickly decommissioned or some resources might be shared between the two environments. But it is likely that there will be some cost increase.

While not exclusive to blue-green deployments, maintaining database synchronization between old and new environments can present a challenge. For example, in a blue-green system that involves frequent or complex changes in schema, it can be tricky to maintain compatibility.

To avoid breaking the live environment, changes in schema must be backwards compatible, meaning that the new system can work with the older one. If they are not, the environments might require separate databases that must synchronize in real time. This bidirectional synchronization presents its own risks, such as inconsistencies and performance degradation.

To address this issue, CI/CD tools, such as GitHub Actions, include database deployment processes that automatically manage schema updates. Sometimes, schema changes that are too complex might negate the value of blue-green deployment.

In stateful applications, those which maintain persistent data across requests, blue-green deployments can present problems. Stateful applications could include shopping carts that keep their contents across multiple visits, or messaging logs. If databases aren’t shared and compatible among environments, this data can be lost.

Microservices applications are often highly complex systems made up of many different individually deployable components. As microservices developers might want to deploy dozens of times per day, the incremental nature of a canary deployment is considered a safer choice.