In our previous article on CI/CD, we briefly discussed blue-green deployments and Canary releases and their role in continuous delivery. These are very effective ways to significantly reduce the risks associated with application deployment. So, in this article we’ll take a closer look at turquoise deployments and Canary releases.
Blue-green deployment and Canary release mitigate the risk of application deployment by giving IT people the ability to revert to previous versions if problems occur during the release process. These two methods make switching back and forth between versions as easy as flipping a switch and can be performed automatically, minimizing the amount of time the user is exposed to error code. Before we discuss either approach any further, let’s distinguish between deployment and release.
How do you decouple deployment from release
Although the terms are often used confusingly, deployment and release are actually separate processes. Deployment is the process of installing a specified version of software in a specific environment, including production, and is more of a technical activity. It doesn’t have to be associated with the release. Publishing, on the other hand, is a business decision to provide new functionality to a customer base.
Traditionally, updates or new features are deployed one day before the release date and may be widely disseminated in the media after they are released. It is well known that things can go wrong during deployment, and because release time is so close to deployment time, there is little room for resolution. If deployment and release are decoupled, frequent production deployments throughout the feature development process can reduce the risk to the IT department. To decouple deployment and release, then, you need code and architecture that allows you to release new functionality without changing your application.
What is a blue-green deployment
During a blue-green release, there are two production environments: the blue-green environment and the green-green environment. Blue is the current version with live traffic, and green is the environment containing the updated code. Only one set of environments has real-time traffic at any one time.
To release a new release, the code needs to be deployed to a no-traffic environment, which is where the final tests are performed. When IT confirms that the application is ready, all traffic is routed to the green environment. Then the green environment is in effect and the release is executed.
This is the first time the new code has been tested under production load (actual traffic). Until the code is actually released, the risk is still there and will never go away. However, if something goes wrong, the IT department can quickly rerouttraffic back to the blue version. So all they have to do is monitor code behavior closely, and even automate it with appropriate tools, to see if the version in the green environment is working well or needs to be rolled back.
This approach is not new. IT departments always create a new version and rerun real-time traffic to that version. Reliability and repeatability through component coding in version control is the highlight of this approach.
How do we get reliability and repeatability? The developer codifies all parameters into version control, a system that tracks all code changes, similar to a database. This includes application logic, build process, testing, deployment process, upgrade process, recovery process, and so on. In short, include all the factors that affect the application. The computer then executes the code and deploys the application in the appropriate environment that matches the exact state encoded in version control.
Before DevOps, this process was often manual and error-prone. Because all changes are documented only, developers can recreate applications and environments based on this. Because two key steps need to be performed manually, this process is too unreliable, leading to frequent problems.
While coding applications and environments is also a manual task, it is only part of the development process, not a separate task, such as creating documents. The same code is coded in version control as in production. Any changes or updates automatically trigger tests to ensure the code is in a deployable state. This way, if there is a human error, the system can find it quickly.
Canary Publishing (Grayscale Publishing)
Similar to blue-green deployments, canary releases begin with two sets of environments: those with live traffic and those with no live traffic but with updated code. Unlike blue-green deployments, traffic is gradually migrated to updated code. It starts at 1%, then 10%, 25%, and so on to 100%. With automated publishing, when the code is verified to work correctly, it can be rolled out to larger, more critical environments. If a problem occurs at any time, all traffic is rolled back to the previous version. This greatly reduces the risk, since only a small percentage of users will use the new code.
Not only can IT control the proportion of users deployed, but Canary publishing can also start with less important users, such as users with free accounts or relatively less important business markets.
Canary release: Live traffic is gradually migrated from the old version to the new version until the update takes effect
Go to the background of Rancherlabs to reply [Canary] and you can get the video demo and common debug published by Canary using Istio.
Cluster Immune System
Cluster Immune System can take canary releases one step further. It connects to the production monitoring system and automatically rolls back the version when user-facing performance deviates from a predefined range (for example, an error rate of 2% higher). This approach identifies errors that are difficult to detect through automated testing and reduces the time required to detect and respond to performance degradations.
By decoupling publication from deployment and leveraging blue-green deployment or Canary publishing, the risk is significantly reduced. At any point, IT can roll back an application to a previous version — a far cry from the traditional application release process.
New technologies and approaches are making this possible for the first time: version control, Infrastructure as code, containers, and Kubernetes all play a role in this new, flexible, DevOps-oriented WORLD of IT.
The author:
Catherine Paganini leads kuBLr’s marketing team, helping to build kuBLr’s brand image from strategy to tactics. Prior to that, he worked in the Marketing Department of the Washington Post.
Thenewstack. IO /primer- Blue…