Blue-Green Deployments
External
- Blue-Green Deployment by Martin Fowler
- Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble, David Farley
Internal
Overview
The idea behind the blue-green deployment technique is that at any time there are two identical instances of the application in operation. One instance takes production load, while the other is being upgraded to the next version of the application, tested, and prepared for production. Then, the traffic is switched over from the current instance to the new one. The sequence is repeated indefinitely. This technique reduces the time it takes to put "done" software in production, and also fastens recovery, in case of problems, as it will be explained below.
Application instance vs. environment. An instance of an application my comprise a large multi-node cluster. We avoid naming it "environment", because we reserve the word "environment" for a different logical abstraction, a multi-application structure that provides complex business functionality to its users. While we can certainly design a workflow that relies on blue-green switch-over at environment level, we want to make sure that components of an environment - the applications - can undergo a blue-green switch-over in isolation from other components of the environment.
One of the most sensitive moments of putting a new application version in production is the cut-over moment. At it simplest, it requires scheduling a maintenance outage: traffic is cut, the old version is shut down, the new version is spun up and traffic is resumed. This strategy ends up in downtime, which is something we want to avoid. Moreover, if the new version breaks, the application will not work. This requires shutting traffic down again, while the old version is restored and put back into traffic. This incurs to significantly more downtime. Blue-green deployments are a solution to this situation.
The application instance being prepared for production could be deployed manually, but that is not advisable. A more efficient approach is to perform the application deployment and testing (and optionally the infrastructure provisioning) as part of a completely automated continuous delivery pipeline.