Manage the risk of releasing new software by first releasing to a small user population, then gradually rolling out to the entire user community. If problems are detected, users can be quickly re-routed back to the old version. In addition to functional testing, this can be used to facilitate capacity testing in a production environment with a dependable rollback strategy. If quality is not an issue, canaries can be used for A/B testing of hypotheses of user engagement. Avoid using canary releases on critical systems that cannot tolerate failure.
What's With the Name?
Canary releases are named after the practice of coal miners who once carried canary birds into the mines to alert them when toxic gases reached dangerous levels — which would kill the canary before affecting the miners, signaling them to evacuate the mine. Likewise, canary releases are intended to signal us to pull a release out of production when things start to go wrong.
Canaries with Microsoft Azure
Canary Releases can be easily achieved on a variety of cloud platforms and services. The example (below) illustrates how this website (DevLead.io) uses Deployment Slots within Azure App Services to direct user sessions to one of two deployments slots named devlead and devlead-Stage1, based on the Traffic %. In this example, Stage1 serves as the canary, with 5% of the users being routed to that particular deployment. Then I can gradually increase the Traffic % for Stage1 or click the Swap button to immediately route all remaining users to the Production slot.
If you are using canaries for A/B testing, you can add additional slots to accomodate testing multiple configurations at once (perhaps A/B/C/D testing). The number of deployment slots available depends on your App Service plan. The bottom tier provides 5 staging slots (in addition to the Production slot) and goes up from there.
Canaries with Amazon Web Services