Blue-Green Deployments: Difference between revisions
| Line 14: | Line 14: | ||
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. | 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. | ||
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_as_Code_Concepts#Delivering_Infrastructure_Code|infrastructure provisioning]]) as part of a [[Continuous_Delivery#Continuous_Delivery_Pipeline|continuous delivery pipeline]]. | 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_as_Code_Concepts#Delivering_Infrastructure_Code|infrastructure provisioning]]) as part of a completely automated [[Continuous_Delivery#Continuous_Delivery_Pipeline|continuous delivery pipeline]]. | ||
=Organizatorium= | =Organizatorium= | ||
Revision as of 01:12, 3 February 2022
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 other. The process is repeated indefinitely.
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.
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.