Pre-requisites:

1.Microsoft Azure Subscription.

2.Basic Understanding of Microsoft Azure App Services.

The concept of deployment slots is used to draw a boundary between production, staging and test environment deployments. And they come in handy when you want to swap a deployment for an environment quicker than performing a new deployment for the environment in question e.g. staging to production.

After a swap, the slot (staging, in this example) gets the previous production environment changes and the production environment gets the staging environment changes. If you don’t like the new changes in the production, you can still perform a swap to get your previous configuration.

As of this writing, Deployment slots are only supported in Standard and above App service plans.

To get started building deployment slots, we browse to our Azure WebApp. In this example my WebApp is called blazorapp001.

Select the deployment slot section and add the staging slot. When it’s done, we select the new staging slot and it will lead us to an entirely new Azure WebApp with its own settings.

The Web Page shows what exists in our staging environment and the one below shows what currently exists in our production environment.

To perform the swap operation, we head to our WebApp – Deployment slots and then swap as shown. Make sure to look at which configuration changes are going to be effected, but as you can see in our first screenshot we selected not to clone any of the settings so this shouldn’t be a problem for us.

The swap operation takes some time and the operation occurs with no downtime on the production app. When it’s done, we can confirm by browsing the URL of our production app which shows the new changes.

In case we don’t like the new functionality, there’s opportunity to rollback by swapping again these two apps.

Extras

Sometimes you may find yourself in a situation whereby you want your beta users to test a few new functionalities in the new production app (beta). This can be implemented by integrating a routing rule within the application code as shown in the example below. I set this on the index page of both my production and staging apps.

<a href="<webappname>.azurewebsites.net/?x-ms-routing-name=self">Go back to production app</a>

The routing name “self” stands for the production environment and we apply this to the staging environment code whereas a routing rule with x-ms-routing-name=staging is applied to the production environment code.

This will enable beta users to switch between the two different application instances. And when the changes are completely approved, You can disable the routing rule.