Canary Deployment: the right way to test your code. Learn how these deployments allow you to test the waters before fully committing a build to production.
Every modification to software comes with the potential for production problems. Application failures often have serious consequences which can result in a loss of revenue and a poor customer experience. Additionally, organizations constantly try to improve their services for a better customer experience. How can you minimize the chance of error and update your application with confidence?
There are various ways to minimize the chance of error. It starts with development which can be by code reviews, test-driven development, or CI system tests. But there are certain problems that do not become visible, unless exposed to production traffic. In this blog, we will explore how Canary deployments allow us to test the waters before fully committing a build to production.
Canary deployments allow us to see how applications react under production load.
Canary deployment is a deployment approach that slowly delivers an application or service to a subset of consumers, so organizations can monitor the application under use and make modifications based on observations.
Once the change is accepted, the update is rolled out to the rest of the users. Because of this control, a canary release is the least risky of all deployment options.
Canary deployments require you to run two versions of the application simultaneously. The old version is labeled “stable” and the newer one “canary.” There are two ways to deploy the update: Rolling deployments and Side-by-side deployments.
You install the changes in stages, mostly a few machines at a time. The other machines operate on a stable version. This is a more common and simple implementation of canary deployment.
When the canary version starts running on one server, a few users will notice the updates.
During this time you can observe upgraded machines, check for errors, performance problems, and listen to user feedback.
With growing confidence in the canary version, it is installed on more machines, until they are all running the latest release.
Once you detect a failure or get dissatisfactory results, you can undo the change by rolling back the upgraded servers to their initial state.
In this method, instead of upgrading machines in stages, a canary version is installed in a whole new duplicate environment.
Consider an application that runs on multiple machines, with a few services and a database.
To deploy your canary version, the hardware resources are cloned. As soon as the canary version starts running in the new environment, it is released for a portion of the user base. This is made possible by using a router, a load balancer, a reverse proxy, or some other business logic in the application.
Here too, you can monitor the canary version and gradually migrate more and more users away from the control version. You will continue the process until you detect a problem or all users are on the canary.
On completion, we remove the control environment to free up resources. The canary version is now the new stable.
Canary deployment is a popular method because it reduces the risk of introducing changes into production, while also lowering the amount of new infrastructure that is required. Companies that utilize canary deployments can test new releases in live production environments without exposing all of their users to the most recent version of the software at the same time.
Squadcast is an incident management tool that’s purpose-built for SRE. Get rid of unwanted alerts, receive relevant notifications and integrate with popular ChatOps tools. Work in collaboration using virtual incident war rooms and use automation to eliminate toil.