About
In this article, I will be explaining what Blue/Green (sometimes, known as Red/Black) deployments are and how they can be done using Azure Web App deployment slots.
Blue/Green Deployments
Blue/Green deployment is a deployment model in which we keep 2 production-like environments on active-active standby. In this case, 1 of the environments is always serving production traffic while the other one can be idle or be used for testing features. So, what happens in this case is that one environment always contains the latest code which needs to be in production while the other environment contains the older production code.
Getting the latest changes in production is as simple as swapping the DNS to point to the environment containing the latest code. Rolling back a deployment which doesn’t meet the expectations is as simple as rolling back to the previous environment containing the older production code.
Azure Web App Deployment Slots
In order to get started with Blue/Green deployment model with Azure Web App, let’s go ahead and create a deployment slot in the Azure Web App. Do note that your app needs to be hosted at a minimum of Standard tier to have the option of Deployment Slots.
After the slot is created, if you click on the slot, you will be taken to another Web App. So what happens behind the scenes is Azure does create another Web App with some more sugar on top of it so that it can be classified as a deployment slot. You can use this slot to push code to this the same way you have pushed to the original Web App.
Swapping The Slots
Let’s assume that you have pushed new changes to the new slot and you would like to redirect the production traffic to that code. Just click on the Swap button, select the slot, check the changes, and click on "Swap".
Azure provides you with a nice difference in the configuration settings which will be changed when you change the slot.
After you click Swap, what happens is that Azure will warm up your deployment slot first to remove the cold start time. Only after the warm-up is complete and the site is online, Azure will swap the slots. What this means is that your users should not notice any kind of downtime while this swapping is taking place. So after a swap, the underlying code and configuration are swapped, not the name of the Web Apps. You will notice that after a swap, “pranavtest” is still in production and “pranavtest-blue” is still a slot. But, if you check the code after a swap, it will be the opposite.
If you are not happy with the new changes, simply swap back to your old code.
Considerations
There are a few considerations to this approach. If you are following a Blue/Green deployment model, you need to ensure that your database (which is present in most of the applications) is backward compatible with the old changes. If you plan on having a separate database for the deployment slot, you need to think about cases like what happens to the transactions which happened between the time you noticed a problem and a rollback was completed?
There are of course benefits like hot swaps, rollbacks etc but you need to consider the architecture of your application.
Until next time!