What is Blue-Green Deployment? A Quick Guide

In a typical environment, you will might have local, development, testing and live environments. As new code is released, it moves from left to right across the environments. Functionality will be built in the development environment, often integrating code with other changes and testing with large datasets, before the codebase moves to test.

The testing team might typically run a set of test protocols or focus on specific bugs, often using real data taken from the live server to more closely reflect the live expectations. Once the test team feel the release is of sufficient quality, a release manager can then decide what should be deployed to the live environment.

The aim is to ensure all environments are closely aligned - running the same versions of middleware, operating systems and other external settings to provide predictable and consistent environments.

Issues This Brings

Even with the most extensive testing, when exposed to live usage, bugs emerge, such as race conditions or unexpected synchronisation issues when under extreme load of real network requests. Traditionally, even though provision will exist to roll back changes in the live environment, this still often incurs the risk of downtime. Once rolled back, further live testing may be required to ensure the old behaviour is as expected.

Introducing Blue-Green Deployment

The idea of blue-green deployment is to introduce an additional live environment, with a load balancer routing traffic between the two environments. These environments are arbitrarily labelled blue and green. At any one time, only one of these serves live traffic; the other is idle.

Changes will be deployed to the idle environment - say, green - and the load balancer then configured to direct live traffic to green, so that it green now becomes active. Blue environment is now relieved from live traffic duties and sits idle, but unchanged. Thus it remains, until green is stable and proven, at which point blue can be assumed to be ready for the next set of changes to be deployed.

The two environments always remain within one set of changes of each other, swapping roles as each set of changes goes live.

Advantages of Blue-Green Deployment

The advantage of this approach is that should the live environment not work as expected, a roll-back - with all the attendant risks and delays - is not required. Instead, the load balancer can simply revert the the active/idle status of the two environments. Roll-back, testing and fixes can then be performed on the idle environment for another attempt at going live.

This lends itself well to agile development where, rather than releasing large updates infrequently, small incremental improvements can be trickled out to users as they come, with the assurance of being able to undo problematic changes.

Divio is a smart cloud platform that can help you do less work, get better results, and pay less for your cloud setup. Contact us today to learn more.