Practice for working with Deployment Slots within Azure App Services

When you make use of Azure App Services you can deploy to different deployment slots.  You can choose to work with three deployment slots (dev, tst, acc) and use the default one as production, but what can you do best regarding this functionality.

Deployment slots

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

• You can validate web app changes in a deployment slot before swapping it with the another slot.
• Eliminate downtime on deployment, and automate the swapping.
• Easy to swap a bad deployment back.

 

Note:”The app (App Service Plan) must be running in the Standard or Premium mode in order for you to enable multiple deployment slots. Everything described in this article is for Azure App Services and then specific Azure Web Apps, Azure API Apps and Azure Mobile Apps.”

Practice

Deployment slots can be deployed/ created easy by making use of the Azure Portal or Azure Resource Templates. Information on deploying Azure Deployment Slots via Azure Resource Templates can be found on a blog post I wrote a few weeks ago:

• Azure Resource Templates and Deployment Slots

Within the Azure Portal (https://portal.azure.com) you need to take the following steps:

1. In the Azure Portal, open the blade of your Azure App Service.
2. Click Settings, and then click Deployment slots.
3. In the “deployment slots” blade click on Add Slot.
4. In the “Add a slot” blade, give the slot a name, and select whether to clone web app configuration from another existing deployment slot.

Before creating deployment slots you need to have a useful pattern. In my opinion it is best to use a deployment slot as a pre production environment. This will lead to the following solution architecture.

This solution architecture makes sure that the development/ test / acceptation environment is completely separated from production. Via the pre production deployment slot you are able to test your application against the production SQL database. With this setup you can't alter any data in pre-production this is why there is a dotted line between the pre production web app and the test / acceptation database. That you could use to test all your CRUD operations. Besides this is also makes sure that the pre production is as close to production as needed for a clear test results.

Considerations

When making use of deployment slots there are a considerations and disadvantages to be aware of:

• The web application and deployment slots are created within the same environment (This is also the case when you create a Azure Web App within the same App Service Plan). This means resources between the two instances are shared, So if you want to do a stress test on pre-production you are certain that it will effect the performance of the production instance.

Besides the above disadvantage also consider the settings that can and can't be swapped:

Swapped:

• General settings - such as framework version, 32/64-bit, Web sockets.
• App settings (you can configure it to stick to a slot).
• Connection strings (you can configure it to stick to a slot).
• Handler mappings.
• Monitoring and diagnostic settings.
• WebJobs content.

Not swapped:

• Publishing endpoints.
• Custom Domain Names.
• SSL certificates and bindings.
• Scale settings.
• WebJobs schedulers.