A Canary Release is a deployment technique where multiple versions of an application are running simultaneously. In this case, the main stable release is seen by the majority of users, but a small subset are either randomly or self-selected to view the 'canary' branch - an experimental version of the application - where this subset is used to expose experimental features to real production users and find usability or potential issues without the risk of deploying to the entire userbase. Canary releases are a great way to roll out new functionality to a small subset of users and either gradually increase the percentage that see the new feature or - if the new features are found to be unstable or do not result in the intended rate of adoption - roll back to the original incarnation of the application.

Canary builds can be achieved through a few different means. One popular option is feature toggling, where logic is executed at runtime via either code or configuration that will cause the application to show or hide a given version of a given block of code. The second method can be achieved via multiple instances of the application, where Server A would hold version 1 of the code, and Server B would hold the 'canary' version 2. In this scenario, some sort of load balancer would route the traffic to one server or another based on a set or rules defined at the load balancer level.

Both approaches have their advantages and disadvantages: in the case of feature toggling, all servers will contain an identical version of the application code, thus making troubleshooting any issues significantly easier as there is ever only one codebase deployed; on the other hand, while the distributed approach requires multiple codebases active at any one time, each codebase has the 'final' version of the feature in question, eliminating the technical debt inherent in creating, maintaining, and eventually decomissioning feature toggles.

For those interested in toggling via the load balancer, Microsoft Azure has recently introduced a new preview function to make this process incredibly smooth. In the App Services section, a new Deployment option entitled Deployment Slots (preview) (formerly known as "Testing in Production") allows developers to leverage GitFlow branching to create test versions of an application and determine the rollout strategy.

To begin using this feature, create a new Azure Web App (note: you must select a Standard or Premium App Service Plan tier to take advantage of deployment slots) and corresponding master and canary branches in git. Navigate to the Deployment Slots (preview) blade for your Web App. Configure the Git connections for the production slot tracking the master branch. Create a new slot and configure that to track your canary branch. In addition to the data tracking your repository, you will also see the ability to set the percentage of traffic to be routed to each slot. So if you'd like to test out your canary feature on 5% of all sessions, just set the canary slot to receive 5% of the traffic and allow the remaining 95% to flow through the production slot.

Next steps

While this is obviously incredibly cool and makes configuring canary releases beyond easy, this method does introduce operational overhead in creating the deployments, modifying the percentages, and eventually decommisioning the slot. Unlike case where if one were to handle this approach in code, we can leverage powerful automation techniques to gradually increase the canary's visibility and eventually remove the canary slot once that feature becomes integrated into the mainline. For instance, one could create an Azure Function to query the monitoring data for the canary build, and if exception rates are at an acceptable level, bump up the percentage of users who will be exposed to the new feature. Of course, Azure being Azure, there are no shortage of possible techniques, tools, and strategies that could be used to take advantage of this process. The correct path is really up to you.