Blue-green deployment
In software engineering, blue-green (also blue/green) deployment is a method of installing changes to a web, app, or database server by swapping alternating production and staging servers.
Overview
In blue-green deployments, two servers are maintained: a "blue" server and a "green" server. At any given time, only one server is handling requests (e.g., being pointed to by the DNS). For example, public requests may be routed to the blue server, making it the production server and the green server the staging server, which can only be accessed on a private network. Changes are installed on the non-live server, which is then tested through the private network to verify the changes work as expected. Once verified, the non-live server is swapped with the live server, effectively making the deployed changes live.[1]
Using this method of software deployment offers the ability to quickly roll back to a previous state if anything goes wrong. This rollback is achieved by simply routing traffic back to the previous live server, which still does not have the deployed changes.[2] An additional benefit to the blue-green method of deployment is the reduced downtime for the server. Because requests are routed instantly from one server to the other, there is ideally no period where requests will be unfulfilled.[3]
The blue-green deployment technique is often contrasted with the canary release deployment technique.[3]
References
- ↑ LaToza, Thomas (2019). "Deployment" (in en). https://cs.gmu.edu/~tlatoza/teaching/swe432f19/Lecture-13-Deployment.pdf#page-24.
- ↑ Fowler, Martin (2010-03-01). "Blue Green Deployment" (in en). https://martinfowler.com/bliki/BlueGreenDeployment.html.
- ↑ 3.0 3.1 Posta, Christian (2015-08-03). "Blue-green Deployments, A/B Testing, and Canary Releases" (in en). https://blog.christianposta.com/deploy/blue-green-deployments-a-b-testing-and-canary-releases/.
 |
