With feature flags, you can control the percentage allocation of users you want to be exposed to a specific feature. This process provides risk mitigation and confirms both usability and scalability. Canary releases, or controlled rollouts, serve as an added layer of protection in case something goes wrong.
What is a Canary Release?
Historically, miners took canaries with them into mines because canaries are more sensitive to fatal gases. If the canary died, the miners would know that it was time for them to quickly evacuate. The same idea goes for canary releases in software development. If you release a feature and you are unsure of its status in the wild, you can deploy it to a small percentage of users to be sure “there are no fatal gases”.
Canary releases provide risk mitigation. If there is an issue with your code, would you want 100% of your users to encounter the issue or 1%? Using a canary release gives you that extra layer of protection when releasing your features. When you are implementing sensitive configuration or infrastructure changes, you want to have that bubble of protection just in case something goes wrong and you need to roll back your changes.
How Does a Canary Release Work?
When you implement a canary release, you deploy a new version of the feature to a small subset of production machines. The canary phase starts with most machines running the old version of the feature, and a smaller subset of machines running your new version. A router (usually a load balancer) will route users to the two sets of machines, with stickiness turned on to ensure that each user has a consistent experience. Users routed to the canary release will keep getting access to the new features while the rest will not.
When Should You Use a Canary Release?
Canary releases are not a good idea when you are rolling out multiple features — save that for feature flags so that you will be able to differentiate where an issue is occurring and with which feature. However, for any single feature, you can use a percentage rollout to release the feature to a small percentage of users, measure its impact against your baseline metrics, and then decide whether or not to kill the canary, which will route the users who were seeing the new feature back to the old feature, or continue to slowly increment the percentage allocation until you reach 100%.
Canary Releases Save the Day
With any feature release, there is a certain amount of risk that you need to account for. With canary releases, you limit that risk to a specified subset of your user base. You can even take this approach one step further by first testing your feature in production with your internal user base, then releasing through a canary release. By adding this layer of risk mitigation, you are not only ensuring a great user experience but also speeding up the release process.
Learn More About Canary Releases
For more information on canary releases, their benefits, and use cases, check out these posts:
- Did Feature Flags Kill the Canary?
- What’s the difference between Feature Flags Vs. Canary Deployment
- Learn more about The Benefits of Feature Flags in Software Development
To stay up to date on all things testing in prod and feature flagging, follow us on Twitter @splitsoftware, and subscribe to our YouTube channel!
Get Split Certified
Split Arcade includes product explainer videos, clickable product tutorials, manipulatable code examples, and interactive challenges.
Deliver Features That Matter, Faster. And Exhale.
Split is a feature management platform that attributes insightful data to everything you release. Whether your team is looking to test in production, perform gradual rollouts, or experiment with new features–Split ensures your efforts are safe, visible, and highly impactful. What a Release. Get going with a free account, schedule a demo to learn more, or contact us for further questions and support.