One article to understand blue-green deployment and canary release

In the previous on CI/CD , we briefly discussed blue-green deployment and canary release and their role in continuous delivery. These are very effective methods that can greatly reduce the risks associated with application deployment. So, in this article, we will introduce blue-green deployment and canary release in depth.

Blue-green deployment and canary release reduce the risk of application deployment by allowing IT staff to revert to the previous version when a problem occurs during the release process. These two methods make switching back and forth between versions as easy as tapping a switch, and can be executed automatically, thereby minimizing the time that users are exposed to error codes. Before we discuss these two methods any further, let's distinguish between deployment and release.

How to decouple deployment from release

Although these two terms are often used confusingly, deployment and release are actually two separate processes. Deployment refers to the process of installing a specified software version in a specific environment (including a production environment), and is more of a technical behavior. It does not necessarily have to be associated with the release. The release refers to providing new features to the customer base, which is a business decision.

In the traditional process, an update or new feature will be deployed one day before the release date, and the update or feature may be widely disseminated in the media after it is released. As we all know, errors may occur in the deployment process, and because the release time is very close to the deployment time, there is almost no room to solve the problem. If deployment and release are decoupled, then frequent production deployments during the entire function development process can reduce the risk of the IT department. Then, to achieve the decoupling of deployment and release, the code and architecture need to be able to meet the requirements of new feature release without changing the code of the application.

What is blue-green deployment

In the blue-green release process, there are two sets of production environments: blue environment and green environment. The blue is the current version with real-time traffic, and the green is the environment that contains the updated code. At any time, only one set of environments has real-time traffic.

To release a new version, you need to first deploy the code in an environment with no traffic. This is where the final test is performed. When the IT staff confirms that the application is ready, all traffic will be routed to the green environment. Then the green environment has taken effect, and the release is executed.

This is the first time the new code has been tested under production load (real traffic). Before the code is actually released, the risk still exists and will never go away. However, if something goes wrong, the IT department can quickly reroute the traffic back to the blue version. Therefore, all they have to do is to closely monitor the code behavior and even automate it with appropriate tools to see if the version in the green environment is working well or if it needs to be rolled back.

Blue-green deployment: no matter when, only one set of production environment has real-time traffic

This method is not new anymore. The IT department always creates a new version and then reroutes real-time traffic to that version. The highlight of this method is to provide reliability and repeatability through component coding in version control.

How should we achieve reliability and repeatability? The developer compiles all parameters into version control, which is a system that tracks all code changes, similar to a database. Including application logic, build process, testing, deployment process, upgrade process and recovery process, etc. In short, all factors that affect the application are included. Then, the computer executes the code and deploys the application in the corresponding environment that matches the exact state coded in version control.

Before DevOps, the process was usually manual and error-prone. Because all changes can only be recorded in the document, based on this, the developer can recreate the application and the environment. Due to the need to perform two critical steps manually, this process is too unreliable, causing frequent problems.

Although coding the application and the environment is also a manual task, it is after all only part of the development process, not a separate task, such as creating documents. The same code as the production environment is incorporated in version control. Any changes or updates will automatically trigger tests to ensure that the code is in a deployable state. In this way, if there is a human error, the system can also find it quickly.

How to understand canary release (grayscale release)

Similar to the blue-green deployment, the canary release also starts in two environments: an environment with real-time traffic and an environment without real-time traffic but containing updated code. Unlike the blue-green deployment, the traffic is gradually migrated to the updated code. It starts at 1%, then 10%, 25%, and so on, until 100%. Through automated release, when the code is confirmed to run correctly, it can be gradually promoted to larger and more critical environments. If a problem occurs at any time, all traffic will be rolled back to the previous version. This reduces the risk to a large extent, because only a small percentage of users will use the new code.

Not only can IT control the proportion of user deployments, but canary releases can also start from less important users, such as users with free accounts or relatively less important business markets.

Canary release: Real-time traffic gradually migrates from the old version to the new version until the update takes effect

Go to the WeChat public account Rancherlabs backstage to reply [Canary] to get the video demo and common debugs for canary publishing using Istio.

Cluster Immune System

The Cluster Immune System can take canary releases one step further. It will be connected to the production monitoring system and will automatically roll back the version when the user-oriented performance deviates from the predefined range (for example, the error rate is 2% higher). This method can identify errors that are difficult to find through automatic testing, and reduces the time required for detection and response performance degradation.

By decoupling release and deployment and using blue-green deployment or canary release, the risk will be significantly reduced. At any time, IT can roll back the application to the previous version-this is a far cry from the traditional application release process.

New technologies and methods make this possible for the first time: version control, Infrastructure as code, containers and Kubernetes can all play a role in this new, flexible, DevOps-oriented IT world.

Author:

Catherine Paganini, leading the kublr marketing team, helped Kublr establish its brand image from strategy to tactics. Previously, he worked in the marketing department of the Washington Post.

Original link:
https://thenewstack.io/primer-blue-green-deployments-and-canary-releases/