Blue-green deployment is an application deployment technique that reduces downtime and risk in software development and deployment by running two identical production environments, traditionally named Blue and Green. It’s a model worth considering for developers and administrators who are concerned about uptime in a frequently iterating code environment.

While Blue-Green was infrequently used in the past because of the hardware requirements of maintaining two coequal production environments, it’s become more common in cloud application development, especially with the advent of microservices.

How it Works

Unlike a more traditional model of deployment where code is moved from a dedicated testing environment to a dedicated live environment, Blue-Green uses two equal environments that switch back and forth between live and testing. While the Blue environment is live, new code is released and tested into the Green environment. Once that code on Green is approved for deployment, network routing is switched to make Green the live environment and Blue becomes the new testing environment (usually after a short delay to ensure that it’s not needed for a rollback in the event of problems with the new live code on Green.) This process iterates back and forth with each code release, with environments cycling between live, previous live version available for rollback, testing and then live again.

Protecting Critical Applications

This kind of development and deployment architecture is especially attractive for applications with critical uptime requirements, as the nature of the model is such that it gives developers immediate rollback access with the flip of a router switch or load balancer to the prior live environment when a deployment uncovers a bug. It also serves as an ongoing exercise in basic disaster recovery practices, as each environment switch is practically similar to a hot-standby swap in an outage situation.

Canary Testing

Blue-Green deployment can also serve as a basis for what’s called “canary testing,” where a secondary live environment is used to serve new code to a small set of users before broad deployment. (The term is a reference to the historic use of canaries or other songbirds in coal mines to detect dangerous toxic atmospheres. If the canary died, the miners knew something was wrong.)

One area of potential challenge from Blue-Green deployment is in the interaction between the live environment, the testing environment and any databases when there’s a database schema change involved between application versions. This obviously isn’t unique to Blue-Green deployment, but it does require strategic scheduling of application upgrades against schema changes and can benefit from judicious use of database refactoring as a way to bridge potential gaps.

Would your application deployment benefit from implementation of a Blue-Green model? Contact us  to learn more about this useful model.