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] and it has similarities with A/B testing.
History
Dan North and Jez Humble encountered differences between their test environments and the production environment while running Oracle WebLogic Server for a client sometime around 2005.[4] To ensure safe deployment, they introduced a method where the new application version was deployed alongside the live system. This approach allowed for thorough testing and easy rollback in case of issues. The team initially considered naming these environments A and B but decided against it to avoid perceived hierarchy. They instead chose color-based names like blue, green, orange, and yellow, eventually using only blue and green since "having two was sufficient".[5] This naming convention was adopted while working on the original Continuous delivery book published in 2010 [6] and became a common term in the industry afterwards.
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/.
- ↑ Kuenzli, Stephen (2010-03-01). "Origin Story: The Blue-Green Deployment Method" (in en). https://nodramadevops.com/2019/04/origin-story-the-blue-green-deployment-method/.
- ↑ Terhorst-North, Daniel (2010-03-01). "Blue-Green deployment" (in en). https://gitlab.com/-/snippets/1846041.
- ↑ Humble, Jez; Farley, David (2010). Continuous Delivery: Reliable Software Releases Through Build, Test and Deployment Automation. Addison-Wesley. ISBN 978-0-321-60191-9.
 |  |
