Sign up for a live Kubernetes or DevSecOps demo

Click here

DevOps Glossary

Blue-Green Deployment

What is Blue-Green Deployment?

Software development teams face unprecedented challenges in terms of their need to release frequent, functional updates to the production environment. The need to manage frequent updates while ensuring exceptional quality and customer experience has led to the development of new paradigms and methods for software development, including Agile and DevOps, underpinned by new software development approaches like continuous delivery, continuous integration, and continuous deployment.

The ability to build, test and release new software at a high frequency is supported by a diverse range of tools and methodologies. Automation is a key factor, with application release automation and build automation software tools playing a significant role in reducing the manual intervention and processes necessary to deploy an update into the production environment. Still, automated deployments always carry a level of risk, as any update to the live environment can result in bugs or errors that negatively impact users.

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 rollback 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 back-up where traffic can be routed in case of errors occur.

Steps for Implementing Blue-Green Deployment

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.

To start, you'll have a Green version of your application deployed to the live production environment on Server A. The router will be configured so that 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. 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 back-up version of your application.

Blue-Green Deployment vs Canary Release - What's the Difference?

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

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

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 are rolled 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.

Sumo Logic Uses Analytics to Monitor Success of Blue/Green Deployments

Software development teams can make use of operational analytics to quantify the success of blue/green software deployments and detect bugs before switching users to the updated version of the application. 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 the deep insight into the performance of new updates and more quickly correlate performance issues with bugs and failures.