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:

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. 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.

• [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

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 Function

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.

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.

In some situations you may want to start using Deployment Slots in combination with your Azure App Service. This means you will have separate deployment slots instead of only the default production slot when running the App Service in Standard or Premium plan mode.

Deployment Slots

Deployment slots are actually live web apps with their own hostnames. Web app content and configurations elements can be swapped between deployment slots, including the production slot. Deploying your application to a deployment slot has the following benefits:

• Validate web app changes in a staging deployment slot before swapping it with the production slot.
• Eliminates downtime when you deploy your web app. The traffic redirection is seamless, and no requests are dropped as a result of swap operations.
• Swap back, If the changes swapped into the production slot are not as you expected, you can perform the same swap immediately to get your “last known good site” back.

Resource Templates

This raises the question of how you are able to deploy deployment slots by using Azure Resource Templates.

A default App Service (web application) looks like the below snip-it.

Deployment slots are in fact resources of the App Service it self and can be deployed as such. This means you can specify them within the resources array of your web application / App Service.

The above snip-it adds a Deployment Slot to the App Service called “tst”. This name is defined within the parameters file of the template. When deployed the host name for the Deployment Slot will be:

• https://[App Service Host Name]-[Slot Name].azurewebsites.net

Defining application settings on a Deployment Slot works the same as defining them on the application it self, and that is by adding a resource of the name “appsettings” to the resources array of the Deployment Slot.

Azure Deployment Slot Connection String Example

This snip-it configures a application setting that is called “insights:InstrumentationKey” to the Application Insights component for Test that is created within the same Resource Template.

Slot Setting

As you may know a Deployment Slot setting has a marking option called “Slot Setting”. This means that the setting is sticky to the slot that gives you the option to keep settings specific for a specific environment. Take for example your production connection strings.

Within the “AppSettings” section in the Azure Resource Template you do not have an option to specify it.

To enable those markings another needs to be added to the App Service it self. This resource needs to be called “slotConfigNames” and must be of the type “config”. Within this resource you have to specify a property called “appSettingNames” that is an array of string items representing the application setting names.

In the above snip-it the application setting “insight:InstrumentationKey” is specified as a “Slot Setting” in order to keep it sticky with the slots.

If you are interested in the complete resource template you can take a look at my GitHub repository:

• https://github.com/MaikvanderGaag/MSFT-Azure-Deployment-Templates