Reading Time: 90s
First, the original problem:
The build team I was leading had figured out there were lots of differences between the test environments and production.Daniel Terhorst-North
We figured the safest way to check a release was to deploy the app side-by-side onto the same physical boxes as the live system.Daniel Terhorst-North
Once the new software was deployed to the system in which they planned to run it, they executed a smoke test to check the software was working properly. If the test passed, they would cut traffic over to the new deployment by reconfiguring Apache (or similar proxy).
This “side by side” deployment solved the problem of there being differences between test and production environments because the software deployment was tested in-situ prior to releasing to customers.
Stated differently: deployment was separated from release.
Deployment of the new software and a quick test of that deployment had to succeed prior to reconfiguring the proxy managing customer traffic to that deployment.
A second important problem they had to solve was what to name this approach and each of the deployments. They wanted to avoid names that had an obvious hierarchy/ordering (A ‘must’ be better than ‘B’) or negative connotations:
If your domains are called Blue, Green, Orange, Yellow, etc. then there isn’t an obviously “best” one. We avoided having a Red domain because that just sounded dangerous. (“You were running in RED??”)Daniel Terhorst-North
Trivia: The ‘Blue-Green’ deployment method is sometimes referred to as ‘Red-Black’. This is because Netflix engineers changed the colors to match their brands’ colors when they adopted the process and built their tools. Different name, same method.