Today there is a great need for enterprises to release their changes faster to the market with high quality. Gone are the days wherein teams used to follow a six-month to one year release cycle to make their changes visible in the market. With SaaS based enterprises, there is a pressing need to make changes to either fix bugs or release newer features so that they can attract more customers. This has resulted in enterprises moving towards full-fledged automation and DevOps.
Despite adopting automation and full-fledged DevOps solutions, there is a need to support recovery in case the changes released to production are not desirable. Hence it is essential to be able to revert to an earlier production version in real-time to avoid or minimize downtime and other related issues such as loss of revenue and/or brand name, resulting due to improper releases. Blue-green deployment addresses this issue, by maintaining two identical environments of which any one is active at any given time and the other is a passive node holding the previous production version.
Below diagrams show the blue-green deployment in action.
Scenario 1: The production version is currently running in Green production instance. The code changes, after successfully passing through DevOps pipeline, have been released to Blue production instance, which was passive until the code changes were released. Load-balancer switches production instance from Green to Blue.
Scenario 2: Blue is currently active, whereas new code changes, after successfully passing through DevOps pipeline, have been released to Green production instance, which was a passive instance until new changes were released. Load-balancer switches production instance from Blue to Green.
Scenario 3: Some issue was detected with new set of code changes, hence the production instance has been reverted to Blue by Load-balancer.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.