It’s a combination of architecture, how stateful the app is, and the technology being used.
It’s important to note that not all applications can take advantage of blue/green deployments. If something doesn’t work, you don’t make the switch, and you can try again. Changes are verified in production without any customers hitting the code, which reduces the risk in the deployments. When switchovers occur, they are seamless because the code has already been running, and there is no need to wait for it to compile or warm-up. Rollbacks are just a matter of switching from Blue to Green or Green to Blue. There are several advantages to this approach.
Blue octopus verification#
For example, if Green is the live environment, deployment is done to the Blue (inactive) environment, and after verification has occurred, a switchover happens, which makes the Blue environment the live environment, and the Green environment inactive. Only one of the environments is ever live, and deployments are always done to the inactive environment.
0 kommentar(er)
