One of the premium features you get when using Azure Web Apps in a standard SKU is the deployment slots feature also known as staged deployment but it is actually more than that.

A deployment slot is an additional Azure App Service Web App instance (W3WP) which is bound to your production Azure App Service Web App of the same name and runs on the same App Service Plan (ASP) that I discuss here. This development slot lets you deploy you test or non-production ready code for testing prior to the release to the live Web App. During the swap operation the site in the staging slot is warmed up by making an HTTP request to its root directory. More detailed explanation of that process is available at How to warm up Azure Web App during deployment slots swap. By default the swap will proceed as long as the site responds with any status code. However, if you prefer the.

In this post I will go over the deployment slots concept and what you can do with it.

What are those deployment slots?

From a (standard) website you can create deployment slots which will actually be Azure Web App instances that are tied to that Website.

A deployment slot will carry the name of the Azure Web App + the name of the slot, for example:

If my Azure Web App is called mysite and I create a slot called staging then my slot will be an Azure Web App with the name mysite(staging) and its url will be http://mysite-staging.azurewebsites.net.

It's important to emphasize that the slot is in itself a regular Azure Web App, it will have its own app settings, connection string, any other configuration settings and even an scm site (https://mysite-staging.scm.azurewebsites.net).

In fact by default each Azure Web App has a single deployment slot called production which is the Azure Web App itself.

You can add more than one deployment slot.

Why do I need this?

The first feature of deployment slots is the Swap Slots and it's used for Staged Deployment

In short, the Swap operation will exchange the website's content between 2 deployment slots.

Later I'll explain what is swapped and what is not but note that swap is not about copying the content of the website but more about swapping DNS pointers.

So in our scenario we have the Production site with index.html that starts with Hello World and our staging slot has the same index.html but it starts with Yello World.

Before swap - http://mysite.azurewebsites.net/index.html will return Hello World...

After swap - http://mysite.azurewebsites.net/index.html will return Yello World...

Now to get this into a real life scenario.

Staged Deployment

Deploying your website in the traditional way, whether deploying via WebDeploy, FTP, git, CI or any other way, has weaknesses that may or may not concern you:

• After the deployment completes the website might restart and this results in a cold start for the website, the first request will be slower (can be significant depending on the website).
• Potentially you are deploying a 'bad' version of your website and maybe you would want to test it (in production) before releasing it to your customers.

This is where staged deployment comes into play. Instead of deploying directly to our production website we create a deployment slot used for staging and we deploy our new bits there.

Then we 'warm' our site (staging slot) by making requests to it and we can start testing our new bits verifying everything works as expected. Once we're ready we hit the Azure Portal's Swap button (or PowerShell/xplat cli command) and the slots will be swapped.

Our customers will not hit the 'cold start' delay and we have more confidence in our new bits.

Auto-Swap

Since we want to test our website before going into production we have this manual step where we hit the Swap button to swap.

But if we only want to address the 'cold start' delay we can configure the Auto Swap feature where the website automatically swaps a configured slot (in our case staging) with the Production slot after the deployment completes.

Currently auto-swap only works when deploying using WebDeploy (deploying through VS will usually use WebDeploy) and Continuous Integration (VSO, GitHub, Bitbucket). FTP and git push will not cause an auto swap.

Auto-swap can take a while to swap (1-2 minutes), until the swap completes any other attempts to deploy the website will fail.

To set this up you'll need to use the Azure PowerShell tool (download)

In PowerShell use the following command:

This command will set Azure Web Apps to auto swap the staging slot into Production slot whenever staging is deployed.

You can use the operation logs in the (current) Azure portal to see the auto swap operation status.

Deployment Slot App Settings / Connection String / Configuration

One important concept to understand about deployment slots is how the configuration works.

A deployment slot is a full Azure Web App and as one it has all the same configurations as any Azure Web App. When you swap deployment slots there are some settings you actually need to keep with the slot and not swap them.

A setting that is not swapped is referred to as a setting that is sticky to the slot.

Some of the default settings that are sticky to the slot:

• Most obvious one is the url - http://mysite-staging.azurewebsites.net/ will always point to the staging slot.
• WEBSITE_HOSTNAME environment variable for the staging slot will always be mysite-staging.azurewebsites.net and this is something we can use in our website code to find it's currently running in the Production slot or staging slot.
• Deployment settings - if you have the deployment profile for the staging slot, after a swap the profile would still point to the staging slot.

  This also includes continuous integration settings - if you hooked your staging slot with a GitHub repository after a swap the hook will still exist between GitHub and the staging slot.

App settings and connection strings are not sticky to the slot and will remain with the website when swapped but we can configure selected app settings and connection strings to become sticky to the slot using a PowerShell command (not yet supported by the Azure portal).

Use this command in Azure PowerShell to set 2 app settings as sticky to the slot

And this command to set 2 connection strings as sticky to the slot

Sticky to the slot configuration is website-wide configuration and affects all slots in that website.

Deployment Slots Traffic Routing

Another great feature for deployment slots is the traffic routing also known as testing in production.

This feature will allow you to route traffic that is coming to your Azure Web App between your deployment slots based on percentage of the traffic.

This feature exists only in the new Azure preview portal.

In the portal under your website there is a tile called Testing in production, click on it to get to the 'Testing in production' blade where you can direct traffic coming to your website between all of your deployment slots.

One usage scenario for this feature is A/B testing.

By default 100% of the traffic will go to the Production slot but you can create a new deployment slot with a slightly different version of your website (differs by what you want to A/B test) and add it there with a 50% value so 50% of your visitors will actually be served from the new slot.

Another scenario for this feature is having a dev slot that is a little less stable which gets 1% of the traffic so you can test feature currently being developed with real traffic.

For more information on this feature.

Wrap Up

I hope that if the deployment slots were just a mysterious link/tile/concept before, you now know how to master them as they can bring lots of value to your production website.

Deployment slots have been an invaluable feature for Azure Web Apps for a long time. To find out how to create slots for Azure Web Apps, you can visit the official documentation [here](https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-staged-publishing' target='_blank). So what makes deployment slots so useful? I summarize some of the benefits below but this is by no means the exhaustive list:

• [Testing in Production - A/B Testing](https://cmatskas.com/azure-websites-testing-in-production/' target='_blank)
• Hot deployments that allow deployment to production with no downtime
• UAT testing targeting a near live environment
• Easy roll out and roll back
• Full or incremental swapping
• DevOps integration with slots (VSTS deployment directly to slot)
• many more

There are also some important caveats that you need to be aware of when using slots:

• Shared resources with the live deployment
• Setting persistence
• Load/Performance testing on slots can affect the live site
• Slots are only available on the Standard and Premium tier
• some more

As long as you're aware of the caveats and treat deployment slots, you can significantly improve the way you perform your testing and deployment to Azure. And now Azure Functions can benefit from this awesome feature, which is currently in Preview like [Proxies](https://azure.microsoft.com/en-gb/updates/announcing-azure-functions-proxies-in-public-preview/' target='_blank)

Enable Function Deployment Slots

As soon as you log in to your Azure subscription and navigate to your Functions blade you'll be met with a new item in the navigation pane:

To start using slots you need to enable the feature first (one-time setting). When you press the + you'll be presented with the following message:

Click on the link to enable the feature in the app settings section:

Notice the message above the (On/Off) buttons. This is one-time opt-in on the Function app that cannot be disabled. Feel free to ignore this as slots can be safely ignored if you don't want to use them.

Creating and using slots

I'll use the portal to showcase how to create and use deployment slots.

I haven't seen any updates to the CLI and PoSH cmd-lets with regards to Azure Function slots . I'll update the blog post once I know for sure.

Let's go ahead and create our first slot. Click on the + button next to the Slots item. Enter a name for your slot (make it meaningful as the slot name will be appended to the Function URL. Press Create to go ahead an create that slot. The slot creation is instantaneous.

With the slot in place, we can deploy our code. It's important to notice that the slot operates on the whole Function app and not individual functions. This means that if you plan on using this feature for testing, you'll need to replicate the whole 'live' Function code. For my example, I went against my own advice as I'm only showcasing the feature and I don't care about my 'live' code.

You'll notice that my new slots comes with it's own unique URL. This is fantastic because I can access this slot in isolation and test it independently from other slots or the code deploying in my 'Production' slot which is the default/live slot. The slot URLs have the following format:

https://yourwebsitename-<slotname>.azurewebsites.net

Swapping slots

Assuming that all our tests pass and everyone has signed off the new code, we can now swap the Production and Beta slots. To do this, you need to use the Swap button which is a new addition to the UI.

This will kick off the wizard that will guide you through the swap steps

Azure Deployment Slot Connection String Function

You need to choose the source and destination slots and the type of swap (simple or with preview). If you want to find the different between simple and swap with preview, check the complete documentation [here](https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-staged-publishing#swap-with-preview-multi-phase-swap' target='_blank). Howwever, if you want the gist of it, see below:

• Keeps the destination slot unchanged so existing workload on that slot (e.g. production) is not impacted.
• Applies the configuration elements of the destination slot to the source slot, including the slot-specific connection strings and app settings.
• Restarts the worker processes on the source slot using these aforementioned configuration elements.
• When you complete the swap: Moves the pre-warmed-up source slot into the destination slot. The destination slot is moved into the source slot as in a manual swap.
• When you cancel the swap: Reapplies the configuration elements of the source slot to the source slot.

Once the swap is complete, you end up with something that looks like this:

Azure Deployment Slot Connection String Functions

With a couple of steps we were able to deploy our code safely to production. I believe that deployment slots are a great addition to Functions and massive Kudos to the team for integrating this feature to the service.

Azure Deployment Slot Connection Strings

I would urge you to give them a go and see how you can benefit your own work flow and deployment process. As always, feel free to let me know in the comments if you have any questions or issues with this feature.