Last Update: Sep 04, 2024 | Published: Nov 24, 2017
In this post, I will explain the role of web app deployment slots in Azure and how to use them.
Normally in the application development world, code goes through several phases before it is pushed into production, such as:
You can create these three separate environments in several ways with web apps:
Some organizations like to take things a little further. You can QA your code quite a bit in a test environment but there nothing like running it on a real system … or even with real users. We can do this using deployment slots.
A deployment slot is a release of a web app. On the face, it is a deployment slot of a web app but it is actually a linked and re-release of the original web app. For example, we can have a production web app and create a pre-production version of it. We can then upload new code into the pre-production deployment slot, running in the same app service plan as production, and test it in a couple of ways:
Once we are happy with the quality of code in the deployment slot, we can promote it into production, thus demoting the old production deployment slot to pre-production.
I have a single web app, called petri, running in an app service plan, called bww.
This web app is running version 1 of my web app code.
I opened the web app, petri, browsed to Deployment Slots under Deployment and clicked Add Slot. The deployment slot is given a new name, petri-preprod in this case, and I opted to close the settings from the original web app.
After a few moments, the new deployment slot appears in the same resource group as the production web app. This deployment slot is effectively its own web app now, with its own application settings, copy of the code, etc.
The deployment slot also has its own URL, which is based on its own name and the name of the original web app. In my case, the URL of the deployment slot is http://petri-preprod.azurewebsites.net.
A new version of the code is uploaded to the deployment slot and can be tested with its own URL without impacting the production system.
When I am happy with the new version of the code, I can return to Deployment Slots in the web app and click Swap.
In the Swap blade, you can select the source and destination deployment slot, where the source deployment slot will be promoted to replace the destination slot.
Note that there are two swap types:
I chose the simple Swap action to replace the production system with the pre-production system. Now, I browse the URL of the production system. It has been updated with the code of the pre-production deployment slot.
Note that the pre-production version of the site now has the previous production code. This means that a rollback is easy to do by reversing the swap.