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

1. Azure Web App deployment slots are used to help roll out new versions of an app without downtime or cold start activation. New version is typically deployed to a staging slot, then after testing and final verification it gets swapped into a production slot.
2. Deployment Slots provide a nice way to implement Blue-Green deployments for Azure Web Apps. This provides many benefits, including: Reduced down-time when deploying.

Azure App Service Deployment Slots

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 Development Slots

• Azure Resource Templates and Deployment Slots

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

ARM Code for Azure Web App Slot Here, slot name is defined inside a property named stagingSlotName. Again, we have made sure that web service exists first before the slot is created by using the dependsOn in the above code. Since it is defined within the resources array of the web app itself, there is no need to link the two. Deploy to Staging Slot now. Now repeat the process for Staging Slot but remember to modify the content of Web page, for example – I would change Production to Staging. Another change will from the steps above to deploy to Staging slot. Swap the Azure WebApp Deployment slot now. Now we have two versions of Web Application running on separate.

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:

Deployment Slots Azure Web App

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