Blue/green deployment - definition & overview

Blue/green deployment is a methodology for releasing new code into the production environment whose purpose is to reduce software downtime, make it easy to roll back new changes, and avoid service interruptions to applications with critical up-time requirements. A blue/green deployment uses two identically configured hardware environments — one that actively serves users and the other environment set to idle. New updates can be pushed to the active environment and monitored for bugs, with the idle environment serving as a backup where traffic can be routed in case of errors occur.

Blue/green deployment is needed and used to reduce software downtime as new code is released into a production environment. Blue/green deployment makes it simple to roll back changes if an error occurs and helps to mitigate service interruption for end-users.

Blue/green deployments have a number of benefits for development teams. These include:

• Testing parity - the testing and production environments truly mirror each other.

• Easy deployment - developers can deploy new code releases at any time since there is no downtime.

• Instant cut-over and rollback - users instantly see the latest release of the production code; by the same token, developers can roll back the code instantly.

• Backup environment - if a server goes down, taking production with it, teams can quickly host the testing environment until the issue is resolved.

The methodology for blue/green deployment is fairly simple to understand. To start, you'll need two identically configured production environments on which you can deploy your application - let's call them Server A and Server B. You'll also need a router that can send user traffic to either server based on your configured settings.

Blue/green testing model: step-by-step

To start, you'll have a green version of your application deployed to the live production environment on Server A. The router is configured so all users can access the live application on Server A. Next, let's say you're ready to deploy an update to your application. You want to ensure that the update won't interrupt service and that it can easily be rolled back if any major errors are found - you need a blue/green deployment model. Here's how to make it happen:

1. Deploy the updated version of the application (blue version) to Server B. Run any applicable tests to ensure that the update is working as expected.

2. Configure the router to start sending live user traffic to Server B.

3. Configure the router to stop sending live user traffic to Server A.

4. Keep sending traffic to Server B until you can be certain that there are no errors and no rollbacks will be necessary. If a rollback is necessary, configure the router to send users back to your Green version on Server A until they can be resolved.

5. Remove the green version of your application from Server A, or update it to your blue version so it can continue serving as a backup version of your application.

Software development teams must understand the risks associated with deploying new software updates to live production environments where they can be engaged by users. An update that causes errors must be rolled back until those errors can be addressed, and this should be done without impacting service to users. Blue/green deployment is one system for achieving this, but there are two notable alternatives: Canary Release and Rolling Deployment.

Canary release vs. blue/green deployment

A canary release is a software deployment strategy that tests the new update on a limited subset of users before making it available for all users. The idea is to minimize the possibility of a costly public application failure. A canary release is done by releasing the new software update on a limited number of servers and monitoring it for bugs and performance issues before making it widely available.

The canary release concept comes from the old mining industry practice of bringing a canary into a mine shaft to check the air quality. If the canary died, miners would know that the air in the mine was filled with carbon monoxide or methane gas and the space was too dangerous to occupy.

Rolling deployment vs. blue/green deployment

A rolling deployment spreads out the deployment of a new software update across multiple phases, often using several servers performing different functions in a server cluster.

Rolling deployment is effective for complex applications that run on multiple servers that make up a server cluster and whose server nodes receive traffic through a load balancer.

Instead of taking the entire application offline to perform an update, software developers can configure the load balancer to stop delivering traffic to a specified server while it is being updated with the new application. Once the update is completed, another server node is taken offline and updated before being brought back online to service users. Rolling deployments ensure that there is always a stable version of the live application available for users and that any errors affect only a small subset of the user base.

Blue/green deployment

With the canary release method, software developers do a small release on a few servers, search for bugs, then do a big release once bugs have been discovered and fixed. In rolling deployments, software updates roll out progressively to minimize the impacts of bugs and allow developers to update the live environment without taking services offline.

Blue/green deployment is quite different from canary release, in that blue/green releases software on a duplicate version of the live environment — not just a limited number of servers. This helps to approximate the conditions of the live environment in testing.

Blue/green deployments and rolling deployments are similar in that they allow for full software updates without taking the application offline, and both can result in some users accessing the old application version while some users access the new one during an update. The main difference here is the hardware configuration, as blue/green deployments must be released on a clone of the production environment while a rolling deployment updates the application directly on live servers.

Software development teams can use operational analytics to quantify the success of blue/green software deployments and detect bugs before switching users to the updated application version. Sumo Logic makes it easy to capture and analyze event logs that can point to newly introduced software bugs, performance issues and other errors that might be present in new software updates. With Sumo Logic, software developers can enjoy deep insight into the performance of new updates and more quickly correlate performance issues with bugs and failures.