A canary release is when you make new software features available to a limited selection of users ahead of a wider release. Sometimes the users selected to participate in canary releases are targeted for specific reasons, such as location, but other times it can be completely random. Whatever the case, getting to the highest software quality is always at the heart of canary releases. Lastly, canary releases lower the risks associated with shipping software considerably.
“Canary releases” get their name from an old coal mining tactic. Miners would release canaries into coal mines in an attempt to gauge the amount of toxic gases present. If the canary survived, well, things were safe.
Thankfully, times have changed but somehow the name still stuck with canary releases. While we care a great deal about birds, we also have the utmost respect for our software users. That’s why performing a canary release helps improve your final release for end users ahead of a much larger rollout.
When it comes to software development and new releases, a canary deployment substitutes a bird for software users (although hopefully in a much safer way), wherein the pre-selected group of users helps you identify bugs, breaks, and hazards of a new feature. With the information collected from your user group, you can then strengthen your feature so it’s ready for a wider audience.
Differences between a canary release and a canary deployment
You might be reading this and wondering how to understand a canary release from a canary deployment or maybe even a canary launch or canary test. That’s more than fair, since all these terms are often used interchangeably at various organizations.
At LaunchDarkly, we consider it a deployment when you push fresh code out to a production environment but without enabling users to access the new code pathways. On the other hand, a release is when you give users access to those new code pathways. And launching is just another word for releasing.
Either way, a canary release and a canary deployment are essentially the same thing. And more often than not, a lot of phrasing accuracy comes down to what people call things within your specific company or team. If your team calls it a canary release, cool. Or maybe your engineering lead prefers canary deployment? Also totally fine.
Whatever name you want to give it, the ultimate purpose is providing a better software experience for your users with less overall risk.
So aren’t canary releases just blue-green deployments?
Speaking of vocabulary, you may be wondering if a canary release is just a different title for a blue-green deployment. The two types of releases are somewhat similar in concept, but we’ll explain where they diverge.
Blue-green deployments are application release strategies for safely updating apps in production with zero downtime. The process for a blue-green deployment typically includes the setting up of two identical instances of a production app behind a load balancer. In this case, one app will usually be responding to user traffic, while the other receives a steady stream of updates from your team's continuous integration (CI) server.
In the case of blue-green deployments, traffic gets funnelled into one production environment (blue) while a new version of the environment (green) is deployed. The new version of (green) will then undergo a heavy set of tests to qualify usability and performance. As soon as things feel solid, users will then be pushed to the green environment while the blue environment remains on standby in the event of any issues. If there is a problem, users can get pushed back to the blue version, ensuring a seamless transition and maximum uptime without anyone noticing.
So canary releases, then, are much more targeted in terms of the user base, and blue-green deployments are not.
Visual Example: Canary deployment followed by a progressive rollout based on geography
How canary releases create higher-quality software
One major selling point to canary releases is they help reduce the amount of anxiety you might feel around a typical release. One of the reasons canary releases can help decrease your stress levels is because, when it comes time for a larger release, you’ll feel a bit more at ease knowing you already tested out your software on real users.
For example, if you perform a canary test and something fails, you’ll feel a lot better knowing there were only a small number of users affected. Then you can roll back the software, fix it, run another canary deployment, and iterate as needed to ensure you’ve got a solid version ready to go for a larger audience.
We know software deployment anxiety is a real thing that can interfere with everything from your job function to vacations to sleep. By steadily building your confidence up through a series of canary tests, you’ll find your anxiety decreases while the quality of your work increases.
Figuring out who to target with your canary releases is also an interesting step within the process. There’s no end to the different possibilities of users who could provide valuable information to your software, whether you sort them by geographic location, frequency of usage, or experience level. The end goal of building better software is always the same, but it’s good to first think about what sort of information you’re looking to get out of your canary deployments.
It’s also smart business sense, because it’s a lot easier to fix a failure from a highly-targeted canary test than something that’s already been rolled out to your entire user base. For instance, if something goes wrong in a wide release and it results in major downtime for your entire base, the ramifications of that will be much more severe as opposed to the same thing happening to a smaller subset of users.
Canary releases and feature flags
In terms of simplifying your release process, something that makes canary releases even better are feature flags. You can skip multiple environments and overly complicated routing configurations by just relying on feature flags to introduce new code to a small portion of users all within your main production environment.
In practice, this would look like a rollout of your application with a new software feature, except no users would be introduced to it yet.
You would then use a feature flagging tool like LaunchDarkly to bring that new feature to a targeted group of users. So while the bulk of your users base is still using the application as it currently exists, the small subset of users in the canary release would have access to the new functionality.
Another benefit of feature flags is they act as a kill switch. So if your canary release causes an issue in production, you can quickly disable the problematic feature via a flag without restarting the application. That enables the canary users to automatically go back to using the old working version of the app.
After testing and quality assurance of the new feature’s performance, you can then easily roll out the new feature to a greater number of users at whatever pace you feel comfortable. When you’re fully deployed, just remove the flag (within the code and LaunchDarkly), and you’ve successfully executed a canary release with feature flags.
Get a firsthand look at how LaunchDarkly can help your release process by checking out a demo.
.webp)
.webp)
