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 production changes, 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.
We head to our WebApp – Deployment slots to perform the swap operation and then swap as shown. Make sure to look at the configuration changes that will be affected, 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.
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 an opportunity to rollback by swapping these two apps again.
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.