Azure Web App Deployment Slots

 

In this post, I will explain the role of web app deployment slots in Azure and how to use them.
 

 

What Are Deployment Slots?

Normally in the application development world, code goes through several phases before it is pushed into production, such as:

1. Development
2. Test
3. Production

You can create these three separate environments in several ways with web apps:

• Shared App Service Plan: You create a web app for each phase in a single app service plan. This reduces costs but it does create a potential for conflicts.
• Separate App Service Plans: A web app is deployed for each phase in different app services plans. There might be an app service plan for each phase. Alternatively, you might have a plan for dev and test and a second plan for production. Isolation does increase costs but you can minimize this by using lower cost/scale plans for test/dev than you would for production.

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:

• Isolated: The deployment slot has its own .azurewebsites.net URL and can be accessed independently by testers.
• Phased release: We can put the deployment slot into limited production, validating the application settings, such as database connection strings, are working correctly (Windows app service plans only).

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.

Creating a Deployment Slot

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:

• (Straight) Swap: You simply swap the deployment slots.
• Swap with Preview: The application settings of the destination (production) deployment slot are copied to the source (pre-production) deployment slot. This allows you to test the new version of the code with the production web app’s database before the actual swap and requires a second step to complete the swap over.

 
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.