In 1986, coal miners no longer relied on canaries to detect toxic gases. All of a sudden, the famous mining tradition was drawn to a close.
However, the past isn’t always as distant as it seems. Not so long ago, we reincarnated the practice.
Modern-day ‘Canary release’ or ‘canary deployment’ is a widely-used deployment pattern for the software development cycle. But instead of detecting deadly gas, it allows companies to roll out new code or features only to a subset of users.
In a similar vein, this percentage of users act like the canary, providing a feedback sample if something goes wrong.
Sounds a little like a feature flag, doesn’t it? It’s not.
Feature flags and canary releases support each other in the deployment process.
Thus, canary testing can be amplified with feature toggles used to separate code releases. This further separates feature deployment and enables or disables functionality for specific groups.
If the canary test uncovers an issue during the deployment process, developers can avert an ‘explosion’ by deactivating that new feature or code.
Therefore, the two deployment forces aren’t mutually exclusive. Instead, canary releases and feature toggles help each other out in the name of a gradual rollout.
Tech titans like Google, Netflix, and Facebook are all using canary releases to distribute deployment in a scalable way. But that’s not the only USP of this software technique. Canary releases also provide the following perks:
● Provide peace of mind during releases when there is a gentle rollout of the new feature.
● Minimize the risk of negatively impacting a large group of users.
● Automate the whole release life cycle.
● Iron out the incompatibilities between API versions and database schema changes.
On top of that, canary deployments can increase user interest in a new feature.
For example, if you release an awesome new feature to a percentage of influencers and get them to promote the release, it provides an increase in demand and boosts your marketing reach.
Roses are red
Violets are blue
Canary releases are yellow, it’s true
If you’re still thinking that canary deployments resemble other software development techniques, you’re not alone. Canary releases are frequently mistaken for both feature flags and blue-green deployments.
However, canary deployments have a different color scheme.
A blue-green deployment is a release strategy that uses two mirrored production environments (blue and green). Within this strategy, all changes get pushed through to either the blue or green nodes. When your team is completely satisfied with the performance, users are routed to the new environment.
Hence, blue-green deployments transfer user traffic to the new code in one go, whereas canary deployments allow you to target the users in small prearranged groups.
Canary deployments give you that extra layer of control when releasing new features.
If we had to summarize their selling point in three words, we’d go with ‘safe, controlled and targeted’.
In addition to that, the morale of your team inevitably increases thanks to the ease of deployment and recovery, making it a win-win for all parties.
Credit for the above piece goes to Tatsiana Isakova, Hang Ngo, and Ellen Stevens.
Subscribe to HackerNoon’s thematic newsletters via our subscribe form in the footer.