Canary Deployments
You might be wondering what canary deployments are.
Canaries were once regularly used in coal mining as an early warning system. Toxic gases such as carbon monoxide or asphyxiant gases such as methane in the mine would affect the bird before affecting the miners. Signs of distress from the bird indicated the miners that conditions were unsafe. The birds were generally kept in carriers which had small oxygen bottles attached to revive the birds, which were too valuable to be considered disposable.
Canary deployments are nothing but releasing a new set of code changes in your application in a slow and progressive manner. What this means is that you release the new code only to a subset of customers and then check if the application is behaving as expected or not. If it is behaving as expected, you keep on increasing the number of users affected by it until all users are using the new version of your application. In case you notice an issue, you can quickly rollback without affecting all the users.
Azure Web App Deployment Slots
In order to configure Canary deployments, let’s go ahead and create a deployment slot.
After the slot has been created, you will notice that the percentage of traffic which is going to the main slot is 100% while it is set to 0% on the slot which we just created -
Let’s change the Traffic % for the Canary slot to 50%. What this will do is that any incoming request to the production URL will be split between the production slot and the canary slot. In other words, 50% of the users will see new changes while the other 50% of the users will see the old changes.
One caveat with this is that this uses a cookie-based approach for redirection. A cookie is stored on your browser which determines that which Slot will serve traffic to you. This can be seen in the following snippet --
But, since you would be gradually increasing (or rolling back god forbid!), this is not a pain.
If you would like to implement Canary Deployments without the caveat of a cookie, you can use Azure Traffic Manager (But, hey! that's not free!).
As you can see, it is fairly simple to start and practice Canary deployments and have a blast radius implemented for your app. This would give you better insights on how your users are reacting and in case of a failure, easily rollback. This feature paired with Release Gates in Azure DevOps is really powerful!
Until next time!