Azure App Service Deployment Slots Demystified

Have you ever wanted to beta test a feature of your web application to a subset of real production users? How about deploy different versions of the same application to a test environment? With Azure App Service Deployment Slots, you can. In this post, I’ll give you a quick, simplified tour. The key here is to not overthink it, as I admittedly did when first learning about them.

Get Started

Getting started is easy.

1. Navigate to your app Service

2. Select ‘Deployment Slots’ from the App Service Menu

3. Click ‘Add Slot’ to create a new deployment slot.

4. Name the deployment slot, and choose to clone settings from your original web app

5. Done! Well, mostly. You now have two deployment slots. Your original web app is sitting in its own slot called the production slot. Its running just as it always has, except in its own slot. All traffic continues to be routed to your original web application in this slot. The new slot you just created is a full fledged web app, complete with its own URL and its own config, empty and waiting for you to deploy code to it. Click on the new slot link and you’ll be taken to the management page of that slot. Notice it is exactly like a regular App Service management page. Its essentially its own application. From the management page, you can click the link displaying the URL of the app to navigate to the running application.

Swap them slots!

Deploy the code containing the features or version you want to test to the new slot. You can download the deployment profile for the new slot from the management page and use it for deploying from Visual Studio. When you’re ready, you can perform a swap of the two slots. Swapping slots at this point moves the new application into the old application’s slot, accessed at the old slot’s URL. The old application moves to the new slot, accessible at the new URL. Most importantly, there is no traffic interruption during swaps!

Traffic Routing

If you don’t want to full on swap slots, you can specify a percent of traffic routed to a slot under the slots management page. On saving, traffic is routed to the slot you configured according to the percentage you specified. Clients do stay on the slot they’re routed to for their entire session, persisted by cookies set on their initial request.

You can direct a client manually to a specific slot by setting a query parameter in a link provided in your app.
Set the x-ms-routing-name parameter value to ‘self’ to direct to the production slot, and to the name of the desired slot to route to the desired slot. Subsequent requests will be routed to the same specified slot.

Here’s an example as provided in the app service documentation that would route to the production slot:

appname.azurewebsites.net/?x-ms-routing-name=self”

and to a staging slot:

appname.azurewebsites.net/?x-ms-routing-name=beta”

You can use this feature to allow users to opt into certain features, then opt out.

There you have it, a swap knowledge snack.  Now say “How many slots could a wood chuck swap if a wood chuck could swap slots” fast 5 times.