Canary deployment, or canary release, is a deployment strategy similar to blue/green deployment, but with one significant change: instead of rolling the new version out to your whole user base all at once, you rollout to only a subset of users as an initial test.
Where did the canary come from?
You might be wondering why a little yellow bird is used to indicate a test release of a new feature. To answer that, we’ll have to go back to the coal mining days of the 1920s. Miners brought caged canaries into the coal mines, because if there was a high level of toxic gases (typically carbon monoxide), the canary would die, alerting the miners to evacuate the tunnel immediately.
In a similar vein, when you release a feature to a small subset of users, those users can act like the canary, providing an early warning if something goes wrong so that you can rollback to the previous, stable version of the application.
Implementing canary deployment
The initial steps for implementing canary deployment are very similar to blue/green deployment: create two clones of the production environment, have a load balancer that initially sends all traffic to one version, and create new functionality in the other version. The difference happens when the time comes to deploy the new software version.
In blue/green deployment, the load balancer would shift all traffic to the green version – the new version – while maintaining the blue version – the old one – as a backup in case something went wrong. Now, we shift some percentage – say, 10% – of your user base to the new version while maintaining 90% of users on the old version. If that 10% reports no errors, you can roll it out to gradually more users, until the new version is being used by everyone. If the 10% has problems, though, you can roll it right back, and 90% of your users will have never even seen the problem.
Benefits and drawbacks of canaries
Canary deployment has a lot of the same benefits as blue/green deployment – zero downtime, easy rollout and quick rollback – plus the added safety from the gradual rollout process. It also has a lot of the same drawbacks – the expense of maintaining multiple server instances, the difficult clone-or-don’t-clone database decision.
Typically, software development teams implement blue/green deployment when they’re sure the new version will work properly and want a simple, fast strategy to deploy it. Conversely, canary deployment is most useful when the development team isn’t as sure about the new version and they don’t mind a slower rollout if it means they’ll be able to catch the bugs.