blue-green deployment
/bloo green dee-PLOY-ment/ · noun · Development · Origin: 2010
Definitions
A deployment strategy that maintains two identical production environments: 'blue' (current live) and 'green' (new version). Traffic is switched from blue to green atomically once the new version is verified. If problems emerge, rollback is instant — just switch traffic back to blue. More resource-intensive than rolling deployments but eliminates mixed-version states.
In plain English: A deployment approach where you set up the new version alongside the old one, then flip a switch to move all traffic over — if something breaks, flip it back instantly.
Example: The blue-green deployment failed spectacularly when someone forgot to run the database migration on the green environment before switching traffic.
Origin Story
The zero-downtime deployment trick using two identical environments
**Blue-green deployment** was described by Daniel Terhorst-North and Jez Humble in the book *Continuous Delivery* (2010), though the practice existed earlier. You maintain two identical production environments -- blue and green. Only one serves live traffic at a time.
To deploy, you push the new version to the idle environment, test it, then switch the router to point traffic at it. If something goes wrong, switch back instantly. The old environment becomes the new idle, ready for the next deployment.
The beauty is simplicity: no complex rolling updates, no partial deployments, and rollback is just a router switch. The downside is cost -- you need double the infrastructure. Cloud computing made this more practical since you only pay for idle capacity when it's running.
Coined by: Daniel Terhorst-North, Jez Humble (popularized in *Continuous Delivery*)
Context: *Continuous Delivery*, 2010
Fun fact: The colors 'blue' and 'green' have no special meaning -- they're just two easily distinguishable labels. Some teams use 'red/black' or 'A/B' instead. Martin Fowler's blog post on the pattern helped standardize the blue-green terminology.