Blue-Green Deployment

Noun · Development

Definitions

  1. Blue-green deployment is a release strategy that maintains two identical production environments, labeled blue and green. At any time, one environment serves all live traffic while the other sits idle. When deploying a new version, you deploy it to the idle environment, run smoke tests and validation against it, and then switch the load balancer or DNS to route traffic to the newly updated environment. If problems emerge, switching back to the previous environment provides an instant rollback. This approach achieves zero-downtime deployments and reduces risk, though it requires maintaining two full production environments, which increases infrastructure cost. Variations include blue-green at the database level, which adds complexity around schema migrations and data consistency.

    In plain English: A deployment approach with two identical setups — you deploy to the unused one, test it, then switch traffic over. If it breaks, switch back instantly.

  2. The key requirement is maintaining two identical production environments, which doubles infrastructure cost. Modern alternatives like canary deployments and rolling updates achieve similar goals with less overhead, making pure blue-green less common in practice.

    Example: 'We moved away from blue-green to canary deployments. Maintaining two full production environments was costing us $40K/month extra.'

    Source: practical tradeoff

Etymology

2005
Daniel North and Jez Humble described the blue-green deployment pattern in early continuous delivery writings, naming the two identical production environments 'blue' and 'green.'
2010
Jez Humble and David Farley formalized blue-green deployment in 'Continuous Delivery.' The pattern minimized downtime by switching a router between two identical environments.
2015
Cloud platforms (AWS, Azure, GCP) made blue-green deployments practical at scale with load balancer target group switching and managed infrastructure.
2020s
Blue-green deployment became a standard strategy alongside canary releases and rolling updates. Kubernetes, Argo Rollouts, and service meshes automated the pattern.

Origin Story

The Two-Lane Highway for Zero-Downtime Deploys

Blue-green deployment is a release strategy where two identical production environments, called 'blue' and 'green,' take turns serving live traffic. At any moment, one environment runs the current version while the other is idle or running the new version. Once the new version is tested and ready, traffic is switched from the active environment to the updated one, and the old environment becomes the standby for the next release. The technique was popularized by Jez Humble and David Farley in their influential 2010 book 'Continuous Delivery: Reliable Software Releases through Build, Test, and Deploy Automation.' While similar ideas existed earlier in mainframe environments, Humble and Farley gave the pattern its memorable name and positioned it as a key practice in continuous delivery pipelines. The beauty of blue-green deployment is its simplicity: if something goes wrong after the switch, you just route traffic back to the previous environment, achieving near-instant rollback. Cloud platforms like AWS, Azure, and GCP later built blue-green deployment support directly into their services, making the pattern accessible without managing duplicate hardware.

Coined by: Jez Humble and David Farley

Context: Popularized in their 2010 book 'Continuous Delivery' as a zero-downtime release pattern.

Fun fact: The colors 'blue' and 'green' were chosen arbitrarily and have no technical significance. Some organizations use 'red-black' or 'A-B' instead, but the blue-green naming has stuck as the industry standard.

Related Terms