Colourful Deployments
An introduction to blue-green, canary, and rolling upgrade deployments
In the current fast-paced world, using continuous integration and continuous deployment (CI/CD) workflows seems to be the only reasonable way to stay on top of software testing , deployment and stability. Numerous articles cover the basics of CI/CD, and in this article, I will focus on brief explanation of three popular deployment strategies blue green , canary and rolling without touching upon their implementation.
Blue Green Deployments
When following the Blue/Green (a.k.a. Red/Black) method, we replicate our “entire” infrastructure for a short time. The replicated infrastructure hosts the new application, while the old infrastructure continues to run until testing is complete and the new stack is adopted. The capabilities to achieve this have been around for a long time, but before the Cloud, it was an incredibly costly deployment method. Now, we can deploy stacks to a whole new environment — allowing for isolated evaluation — and thanks to the Cloud, at minimal costs. Once testing is complete, we switch our application over to the new version and shut down the legacy stack.
As seen in the diagram , Blue portion represents the current environment version, while the new variant that needs to be deployed is the Green Portion, typically this happens via DNS Change or putting a Load balancer in front .
Canary Deployments
Canary is about deploying an application in small, incremental steps, and only to a small group of people.There are different strategies to choose which users will see the new version: a simple strategy is to use a random sample; some companies choose to release the new version to their internal users and employees before releasing to the world; another more sophisticated approach is to choose users based on their profile and other demographics.
As we gain more confidence in the new version, you westart releasing it to more servers in our infrastructure and routing more users to it.
Canary release is an application of ParallelChange, where the migrate phase lasts until all the users have been routed to the new version. At that point, you can decommission the old infrastructure. If you find any problems with the new version, the rollback strategy is simply to reroute users back to the old version until you have fixed the problem.
Rolling Upgrade Deployments
Rolling deployment is the most common deployment strategy offered by cloud vendors and orchestrators. In short, this process is about slowly replacing currently running instances of our application with newer ones. The process is best illustrated with the following animation:
