Azure Deployment Slot Connection String Example
Azure Connection String Deployment Slot Setting
Azure Deployment Slot Connection String Functions
Azure Deployment Slot Connection Strings
Azure Deployment Slot Connection String Function

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.

Alright, let’s look in more detail at how to set up Azure deployment slots and what the major benefits are. Setting Up Azure App Service Deployment Slots. Creating a deployment slot is very easy and, as always, there are many ways to do it. You can use the Azure Portal, Azure CLI, Azure PowerShell and the Azure Management API.
Deployment slots or Azure slots are actually instances of Azure Web Apps which are tied to that website. A deployment slot will carry the name of the Azure Web App + SlotName. For example, if my Azure Web App is called DebDemo and I create a slot called staging, then my slot will be an Azure Web App with the name DebDemo(staging) and its url.
A custom warm-up is a URL that Azure will hit after code is deployed to the offline deployment slot or slots. This gives the app a chance to run custom warm-up code before the slot is swapped into production. The documentation mentions two app settings you can use to set up a custom warm-up.
To configure an app setting or connection string to stick to a specific slot (not swapped), go to the Configuration page for that slot. Add or edit a setting, and then select deployment slot setting. Selecting this check box tells App Service that the setting is not swappable.

Important to note here is the connection string name: Rider will generate a connection string that can be used by our application when running as a web app: The Azure Publish to Web App run configuration can deploy ASP.NET Core web apps (on any platform), and.NET framework web apps (on Windows).

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

Azure Deployment Slot Connection String