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

  1. ↑ LaToza, Thomas (2019). "Deployment" (PDF). Archived from the original (PDF) on 2020-01-14. Retrieved 2020-01-14.
  2. ↑ Fowler, Martin (2010-03-01). "Blue Green Deployment". Archived from the original on 2020-01-10. Retrieved 2020-01-14.
  3. 1 2 Posta, Christian (2015-08-03). "Blue-green Deployments, A/B Testing, and Canary Releases". Archived from the original on 2018-03-30. Retrieved 2020-01-14.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.