A canary deployment, or canary release, allows you to rollout your features to only a subset of users as an initial test to make sure nothing else in your system broke.
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: 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. When you deploy the new software version, you 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.
Note that infrastructure changes and configuration changes should always be tested with canaries because of their sensitivity.
Benefits and drawbacks of canaries
Canary deployment benefits include zero downtime, easy rollout and quick rollback – plus the added safety from the gradual rollout process. It also has some 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.