What are Azure Deployment Slots?
Azure Deployment Slot is a very useful feature of the Azure App Service. With this feature, it is possible to create one or more slots that can host different versions of your app. You can then swap these deployment slots without causing any downtime for your users.
When you add your first deployment slot in your app service, let’s call it staging. Then this would become the place where you can deploy the new version of your app. After validating this new version, you can swap it with the current production slot.
After swapping, the production slot becomes the staging slot. The staging becomes the production slot. If there is a problem you can roll back your changes by swapping back. With this, it is very easy to return to the last-known-good state of the app.
Most important features
- Multiple versions of the same app in your app service.
- Each slot has its own URL.
- Swapping and rolling back is very easy
- Redirect part of the traffic to the staging slot, so you can test the new app under load.
- Each slot can have shared or slot specific settings.
How to create deployment slots
Creating a deployment slot is very straightforward. In your AppService, you need to locate the Deployment Slot menu and provide the name. The URL for the new deployment slot will be your appname-slotname. So if your original app URL is appname.azurewebsites.net then the URL for the new slot will be appname-slotname@azurewebsites.net
How to deploy to your slot
There are different ways to deploy to your deployment slot. The easiest is to right-click on your VS.NET project. Select publish and then create a new publish profile. Then select an existing AppService plan and choose to stage. You can also download the publishing profile for the slot and then import it to your Visual Studio project. Another quick and dirty solution is to clone the git repo for the deployment slot and then copy your binaries to the repo. Commit and push and that is all.
Other ways to do this are using Azure DevOps or other CI/CD systems like Jenkins.
What happens when swapping
When the staging version looks good and it is ready for deployment then all you need to do is perform a swap. All we need to do is to click the swap button. What happens during swapping is the following:
- Slot specific settings are moving from old slot to new slot.
- App in the new slot is restarted and gets warmed up
- New traffic gets redirected to the new slot. Old slot servers the existing request but not receiving new ones anymore
- Old production slot moving to the staging slot, settings applied and restarted
Pricing tiers
To be able to use a deployment slot, you will need to switch your AppService pricing plan to one of your paid tiers. Free, Shared and Basic do not offer deployment slots, unfortunately. The obvious choice here is the Premium AppService plan. This is the cheapest plan that supports deployment slots.
Conclusion
Deployment slots is a terrific feature for your AppService. You can do deployments without the downtime. You can test the new version before putting it into production. Slots can have shared configuration settings and slot specific ones. Also, you can direct a certain amount of traffic to your staging slot to see how it behaves under live traffic. If something fails then it is very easy to get back to your last working version. If you have a critical application then this is a welcome addition, so it helps cut down stress for you and for your customers.
Pros
- Zero-downtime deployments by warming up new versions
- Testing in production
- Great way to do validation before putting into production
- Easy to go back to last known state
Cons
- You will need a Premium AppService plan as Free, Shared and Standard are not supporting this feature.
Top comments (0)