What is a canary release?
So you’ve planned, built, and debugged some important app updates - and now it’s time to release them into the real world! Congratulations! But wait - have you thought about how you’re going to do this so that in case something goes wrong, most of your users are unaffected?
To ensure this, consider a canary release of your code. What is a canary release? When software developers perform a canary release, they deploy a new software feature or version to a small set of users before releasing it to the wider user base. This is a software deployment technique to reduce risk. In case the functionality of your app breaks, the app’s performance is affected, or your app faces security problems, most of your users are unaffected. The goal of a canary release is to gauge the impact and improve the chances of success of a larger release. If the initial subset of users loves the new update, chances are the wider audience will like it too. If the first set of users faces problems, you can go back to the drawing board and iterate.
Here’s a diagram of what canary releases look like when staggering the release based on geography:
In this article, we’ll look more closely at the canary release. We’ll first find out where the term came from, clarify its difference from the canary deployment, consider when to use and when to avoid canary releases, and finally provide an example of how to implement a canary release. By the end of this article, you’ll know whether and when the canary release is an appropriate technique for your situation.
Let’s begin by understanding the origins of the term. What is the metaphorical canary in a coal mine?
Where does the term ‘canary release’ come from?
The term ‘canary release’ is inspired by the historical practice of miners taking canaries into coal mines. Because canaries were more sensitive to dangerous gases than humans, any sign of distress from the birds was an indication that the miners needed to evacuate.
Similarly, when modern software organizations employ a canary release, the initial subset of users that receive the app update act as the metaphorical canary in the coal mine. Just like a real canary, the canary release minimizes the potential impact of the release, giving developers more margin to address an issue before it can cause widespread disruption.
Canary release vs. canary deployment
The canary release and the canary deployment are similar: Both involve releasing a new version of software to a limited set of users before a broader rollout to all users.
There are some important distinctions, however. Although some organizations use the term interchangeably, others make a distinction between whether users can choose to try the new version of the software (canary release) or whether the decision is made for them (canary deployment).
Canary releases and canary deployments can also be distinguished by how the split takes place: splitting branches into a stable branch and a canary branch is done during a canary release. Releasing the updated software to a subset of users or load-balanced machines is a canary deployment.
However, for the purposes of brevity and understanding in this article, we’ll be using the two terms interchangeably.
How to approach a canary release: Important steps to take
Here is one approach that a team can take to execute a canary release or canary deployment:
Release a canary branch alongside the stable branch. Allow users to choose which branch of the software they want to try.
Based on certain user attributes—such as preferences, tech-savviness, or seniority—route a subset of users to the new version of the software.
Deploy the new version of the software to a small set of machines, relying on the load balancer to route a small percentage of users to those machines.
When to use canary releases
Some situations in which a canary release strategy might be appropriate include the following:
New functionality with high risk: When rolling out a substantial functionality update with a high risk of failure.
Feature that cannot be tested otherwise: When you have a feature that cannot be tested with traditional methods or in a regular testing environment.
Verification in production: When you have functionality that can only be verified in a production environment.
Limiting blast radius: When you are unsure if something might go wrong with the update and you want to limit the potential damage.
Permissioning: When you want to give select users access to a new feature.
When to avoid canary releases
While canary releases are ideal for some situations, they are not always the go-to strategy. Scenarios in which you might want to avoid employing a canary release include the following:
Life-critical applications: These are life-critical applications where the slightest malfunction could cause significant harm. In these applications, it’s necessary to carry out comprehensive testing so that the confidence level of the technical success of the release is so high that a canary release isn’t necessary and the entire package can be rolled out at once. Examples include applications that can threaten human life or critical infrastructure if not tested comprehensively.
Sensitive applications: For sensitive applications (such as managing patient health records or financial transactions) in which a malfunction could lead to dire consequences. In this case as well, developers and QA engineers need to have conducted thorough testing, ensuring that technical success is almost guaranteed, before the update is rolled out.
Difficult database rollback: When database changes or schema updates may have a global impact but would be difficult to roll back.
How to implement a canary release
How might you go about implementing a canary release? Some organizations leverage platforms that manage deployment strategies for them. Others implement it themselves through load balancer or API gateway configurations.
Reviewing a simple implementation in pseudocode will be helpful for your understanding of canary releases.
Let's imagine that we are adding a new feature to our in-app chat. We have already developed and tested the feature in isolation. Our application is normally deployed to 10 different servers, and we use a load balancer to distribute user requests evenly among those 10 servers.
The following pseudocode demonstrates how we might configure our load balancer to perform a canary release:
With every server given equally weighted load distribution, user requests will be (on average) distributed across all 10 servers. The tenth server, which runs the application version with the canary released feature included, will receive 10% of the user visits.
In practice, the DevOps team will monitor and assess the feature’s performance, tracking key performance indicators such as load time, error rates, or user engagement metrics. If no issues arise, the load balancer can be reconfigured to incrementally increase the share of users who will have access to the feature.
When adopting a canary release strategy, leveraging a robust monitoring and alerting mechanism is essential. Issue detection must be quick, and rollbacks (if necessary) must be easy to carry out.
Canary releases for in-app chat, calls, and live streaming
In this overview of canary releases, we’ve explored when to use canary releases and when to avoid them. We considered the nuances that differentiate canary deployments from canary releases. Finally, we looked at a pseudocode representation of a load balancer configuration that implements a canary release.
If you’re looking to build new features—such as in-app chat or live video streaming—you can use canary releases to roll out your features incrementally for testing among a subset of your users. In this way, you can reduce your risk and limit the impact of bugs in new features.
To further lighten the load on your developers, freeing them up to focus on your business’s core competencies, you can consider leveraging the robust SDKs, APIs, and Chat UIKits of the Sendbird in-app communication platform. With cross-platform and multi-language support Sendbird’s tools will help you build and launch robust features faster.
Contact us to learn more, start your free trial, or sign up for our free forever Developer plan!
Happy in-app communications building! 💬
