Azure App Services — Deployment Slots
Deployment Slots is a feature offered by Azure App Services, which allows you to create separate environments for deploying and testing your Web App, before making the app available to all the end users. Each Deployment Slot represents a separate instance of your app, which can be used for various purposes such as staging, testing or production. In this article, I present the benefit of this feature and how to use it.
If you are new to Azure App Services and would like to know more about this service, and how to use it, check the article Azure App Services — Monitoring, Logging and Autoscaling.
Deployment Slots offer a good strategy to manage and deploy multiple versions of your app simultaneously. This capability allows you to have distinct environments, where you can run different versions of your app concurrently. With this approach, you can release a new version of your app in one environment, while keeping the latest version in another environment. These are some benefits of this feature:
- Route Traffic Control — Testing and Feedback: you can direct a percentage of user traffic to different slots, allowing you to control the exposure of the new version of your app to your users. This allows you to validate a version of your app (such as new features, bug fixes, performance improvements, functionality and user experience) in a separate environment before promoting them to production, helping you to ensure the stability and reliability of your application, and it also allows you to get users’ feedback, before making it available to all the end users or even before swapping it to the production environment.
- Good Release Control and Seamless Transiction: this allow you to control the exposure of the new version of your app to your users, by gradually increasing the number of users accessing the new version, ensuring a smooth transition.
- Mitigate risks, running two versions concurrently, provides more safety in case any unforeseen problem arises in the new version, cause it allows you to easily redirect the traffic back to the stable environment while you solve the issues.
- Eliminate downtime, by adding a version to a slot, you can warranty that the slot is warmed up before being swapped to production, eliminating the downtime when you deploy your app to production.
- Easily roll back, in case you need to revert the deployment, the other environment will have your previous production version, which can be easily and immediately swapped, and your previous production version with the stable version will be on place.
You don’t need to pay for additional Deployment slots, you only pay for the App Service Plan.
With Deployment Slots you can have isolated stages of your apps deployment process, so you can have slots for development, testing, staging, and production, each with its own configuration settings and dependencies.
Deployment Slots can also be linked to your source code repository, enabling continuous deployment. This means that whenever you push updates to your repository, the changes can be automatically deployed to the corresponding deployment slots for your environments.
Some settings of your app can be swapped, and others can not. Settings such as App settings, Connection strings, public certificates, Path mappings, can be swapped, while settings such as Custom domain names, Scale settings, Always On, Cross-origin resource sharing (CORS), are not swapped. If you want to check a complete list of the settings that are and are not swapped, please check this Microsoft Docs page.
Creating Deployment Slots in Azure App Services
To demonstrate how to work with Deployment Slots, I created a simple ASP.NET Application and I’m going to deploy it to an App Service. If you do not have an App Service yet and would like to know how to get started with this service, please check the article Azure App Services — Monitoring, Logging and Autoscaling.
Note that in order to use Deployment Slots feature, the App Service Plan must be Standard or higher.
In Azure Portal, go to the App Service and select the “Deployment slots” menu:
As it shows, at this moment there is only the App Service that can be selected in the publish window, this is the single Deployment Slot that we currently have, for Production. So let’s use this one to deploy the .NET Web Application to the App Service, using Visual Studio:
Then click on “Publish”:
On the App Service page, get the domain URL and access the app:
This is the application running in the App Service:
Let’s create a new Slot, for that, go to the App Service and click on “+ Add Slot”, add a name and select the option to clone the settings from the current app (attention: if you want to have a separate stage environment, you should have a specific settings for it):
Now you should see two slots:
We can also configure the percentage of the route traffic that we want to direct to each environment. On the deployment slot page, you can update the Trafic percentage. This way each access to your app can be redirected to the production or the stage slot:
I’ve made a change to the app, so now we have the app version 2:
Now, in the publish window in Visual Studio, you will be able to select the newly created slot, to deploy your app:
In case you want to deploy to the production slot, just select the App Service, instead of selecting the deployment slot.
After publishing the app, open a new browser window and access the app using the domain appservicesdsdemo.azurewebsites.net, and you can be redirected to the newly deployed version or to the previously deployed version (access the URL on diff pages and you can be redirected to diff versions):
Specific domain for different slots
Deployment Slots also provides a specific URL for the specific slots, so in case you only want to access the app deployed on stage for example, you can always access it by using the stage app domain. To check it, go to the deployment slots page and select the stage slot:
And access using the domain appservicesdsdemo-stage.azurewebsites.net:
Swapping the slots
Now that our app was already tested on stage, let’s swap it to the production environment. For that, go to the App Service in Azure Portal and in the Deployment slots page, click on “Swap”, double check the Source and the Target, and click on “Swap”. This will swap the deployment slots and will deploy the new app to the production slot (the swap action warms up both slots, to make sure that there is not any downtime):
Accessing the production domain, you can now see the new version deployed:
And if you access the stage domain, you can see the Version 1 that was initially deployed:
Conclusion
Deployment Slots provide you with the benefit of having great flexibility to manage and test multiple versions of your app simultaneously, providing a reliable and controlled deployment process that maximizes user satisfaction and minimizes disruptions. With this feature, you can reduce the release risks of your apps and ensure a smooth transition between the different versions of your apps.
