Understanding Deployment Slots in Azure App Services
Azure app services are heaven-sent for developers. This is mainly attributed to the array of features that come along with it, making the lives of the developers a breeze.
Some of the most popular features include autoscaling, easy authentication, offline syncs(for mobile apps), hybrid connections, and so on.
One feature shared by these apps and probably the most underrated out of all is the Azure deployment slots.
In this post, we are going to understand what are Azure deployment slots and why we think it is one of the best features to be rolled out from the house of Azure.
Table of Contents
- Brief background
- What are Azure deployment slots?
- Why deployment slots?
- Working of Azure services deployment slots
- Practical applications of Azure services deployment slots
- Conclusion
Brief background
Here is a very common scenario that happens in the development world- developers push an application to the production stage after performing testing and other miscellaneous processes. Users may then access the website through an endpoint, mostly through the domain name(For example - www.application.com).
Now, if we have to release the next version of the same application, then we have to first push the latest solution into a staging environment for which the environment settings should be taken care of. In other words, an exact replica of the production environment has to be achieved in the same settings manually. This is a very time-consuming job.
Another major hassle in release management is rollback. If the latest release is having issues or bugs, it is required to roll back to the previous version manually which is again a daunting task. You have to revert the settings and environments - all these are quite overwhelming for the developers. The biggest issue of rollback and update during release is that users cannot use the application during that time leading to downtime.
This is where the Azure deployment slots come into play, saving you from the complexities and unnecessary issues during the release of an application.
What are Azure deployment slots?
Azure deployment slots allow your web apps to function in different instances called slots. Slots are different environments accessed through a publically available endpoint. One app instance is always assigned to the production slot, where you can toggle between multiple app instances on demand. Apps running under the apps service plan can hold multiple slots, while for the under-consumption plan, only a single slot is allowed.
Why deployment slots?
Flexibility of swapping instances
Swapping of different app instances from source to target takes place with no downtime, giving users the best experience anytime, anywhere. Traffic redirection is seamless, and no requests are left out because of a swap. If a function is executed during a swap, the execution is uninterrupted, and the next triggers are redirected towards the swapped app instance.
Rollback options
Another advantageous feature of the deployment slot is the rollback option. If your team is unhappy with the latest update, you can roll back your app to the previous version within the same app service. This eliminates downtime allowing your users to enjoy an interrupted service.
Working of Azure services deployment slots
Suppose that you have deployed a website in a web app. This web app has a custom URL address https://www.azure-slots.com. Now your team has created a new version of the website,, and you want to test it before pushing it to the production environment. So you create a deployment slot called staging for pushing the new version, which has the URL - https://www.azureslots.staging.azureservices.net.
Azure makes sure that the staging slot has the same configuration values. As a result, it uses the same database and cache values that the production slot does.
Now that the new version is ready in the deployment slot, it is to be deployed in production. You can push the new version to production by swapping.
First, the source slot will be warmed up. Then Azure launches requests to the root slot. Finally, Azure swaps the virtual IP addresses of the source and destination slots, thereby swapping the URL of the slots. It is also subjected to certain settings that are specific to the target slot. For example, publishing endpoints, custom domain names, etc.
Practical applications of Azure services deployment slots
Creating an App service resource
The very first thing to do is setting up an app service with a sample web server. This is to test changes and perform the swap. The entire process involves the following:
- Create an app service slot with a sample code
- Create a deployment slot
- Connect your slot using the CI-CD approach to enable auto-sync. This will end up making changes to the code base, and ultimately firing up the slots for a swap.
Once your app service is ready, you will see a webpage displayed with content indicating that your application is active and running.
Creating an app service slot
The next step is to create your staging slot. This can be done effortlessly from the Azure portal. Here are the steps -
- Navigate to your Azure app service created in your environment.
- Click on the deployment slot in the left side panel and choose ‘add slots’ to create your staging environment.
- Give it a name like “Staging” so that it will be easy to identify.
At this point, you will see that the deployment slot is ready. You will see a new app service slot in your resource group dedicated to hosting the code pushed from the repository. The staging slot will be under the name ‘Staging/’ in your resource group.
Now that the staging slot is initialized, it is time to push your code from repo to the staging slot. To do that -
- Navigate to the deployment slot and click on the newly created staging slot
- Go to the deployment center for the staging slot and choose the repo location of your choice.
Swapping production slot with staging slot
This is the last step that involves just a click of the swap button. Once done, you will experience the swapping of the slots. Navigate back to your production slot, and in the ‘deployment center’ click swap to initiate swapping. Then enter the source and target repo to specify the source and target from where you are deploying to.
Finally, you should see a success message indicating that the swapping has been completed successfully. Now you can see your application updated in production. Azure also provides miscellaneous features such as auto swap and swap with preview, which involve changing settings in the deployment center.
Conclusion
As you can see, there are only a few steps involved in swapping two slots. However, don't take it very lightly on the production running apps. It is advisable to test your application in a non-production environment before deploying into production, as you never know when you can experience trouble during the swap.