Azure App Services are extremely useful for developers. It offers Web Apps, API Apps, Mobile Apps and Function Apps (that run Azure Functions). These apps are incredibly powerful and can literally get you up and running in minutes. They provide a host of amazing features like (auto)scaling, easy authentication, offline sync (for Mobile Apps), hybrid connections and much, much more. One feature that these apps share is probably the most underrated one that many people don’t know about: deployment slots.
Deployment slots are incredible! They are the reason for many people to start using Azure App Services, like Web Apps. Let me explain why.
Suppose that you have a Web App deployed in an Azure App Service and it has a URL like production.website.com. In Azure App Services, you can very easily add an additional deployment slot. This is a full-fledged App Service – in this case, another Web App – that sits next to your original Web App. The deployment slot has a different URL, maybe something like staging.website.com. Your users would be accessing your original Web App because that is your production environment slot. You can deploy a new version of the Web App into a secondary deployment slot, so you can test it before it goes live.
Instead of deploying your Web App to a staging slot, you could have deployed it as whole new App Service. But here is the magic of deployment slots: you can now swap the staging deployment slot with production within your same App Service. When you do this, users will notice almost nothing and experience no downtime. The swap functionality of the deployment slot takes care of this magic. Isn’t that awesome?
Before I tell you even more about what make Azure deployment slots awesome, let me state the facts about deployment slots:
Alright, let’s look in more detail at how to set up Azure deployment slots and what the major benefits are.
Creating a deployment slot is very easy and, as always, there are many ways to do it. You can use the Azure Portal, Azure CLI, Azure PowerShell and the Azure Management API. I’ll show you how to do it using the Azure Portal.
In the Azure Portal, navigate to your App Service – let’s say it’s a Web App – and click the deployment slots menu item:
Now you see the Add Slot button, which opens the Add Slot dialog, to the right of the screen. Here, you need to enter a name, and choose if you want to copy the configuration from another slot, or not at all. Click OK and voila, you have a deployment slot!
Choosing to copy the configuration is important because your app probably does things like connect to a database or cache and has specific connection strings in these settings.
When you have created a deployment slot, it is empty, just like when you create a new App Service. You need to deploy a version of your app to the deployment slot before you can use it.
You can use the same tools and techniques that you use to deploy your app to the App Service: through Visual Studio, using something like VSTS (Visual Studio Team Services) or Octopus Deploy, using Web Deploy or any number of other technologies. Selecting a deployment slot to deploy to from Visual Studio looks like this:
One of the major benefits of deployment slots is that you can swap them. What does that mean?
Suppose that I have a website deployed in a Web App. This Web App has the custom URL https://www.azure-overview.com/. I have created a new version of the website and want to test it before publishing it. So, I create a deployment slot called staging, which has the URL http://azureoverview-staging.azurewebsites.net. I’ve made sure that the slot has the same configuration values so that I use the same database and cache as production does. I’ve deployed the new website in the deployment slot and I’m happy with my changes and want to deploy to production. I can do this by performing a swap:
I can do this from the Azure Portal, Azure CLI, Azure PowerShell and the Azure Management API. In the Azure Portal, I can choose what the source and destination slots are and click OK. This will swap the slots and will deploy my changes to production. Here’s the thing: users will experience no downtime!
And that’s because a swap does the following:
This results in a seamless transition to production. Users experience virtually no downtime. I say “virtually” because users that are doing something that depends on the state that is in memory of the Web App will lose this state. But you shouldn’t keep state locally in an App Service anyways in Azure. as you should assume that everything in Azure is volatile.
After a swap, the “old” website will be in the staging slot and the “new” website in the production slot.
If you aren’t happy with the version in production, you can easily roll back your deployment. Simply swap back to reverse the effect!
You can swap deployment slots manually, but you have more options that you should consider.
Auto Swap
You can choose to swap automatically to a slot when there is a new version of your app in a deployment slot – this is called Auto Swap. Simply enable it in the Application Settings of the deployment slot:
Swap with Preview
You can choose to swap with a preview when you perform a swap from the Azure Portal. This does the following:
If you use something like VSTS (Visual Studio Team Services), you can also leverage deployment slots and the swap feature. You can deploy a new version of your app to a deployment slot and then swap it using steps in a release definition. The illustration below shows this for a release definition in VSTS:
Besides swapping, deployment slots offer another killer feature: testing in production. Just like the name suggests, using this, you can actually test in production. This means that you can route a specific percentage of user traffic to one or more of your deployment slots:
With testing in production, you can have some users test the new version of your application. This way, you can see if and how they use new features. In order to find this out, you need to make sure that you monitor everything, with something like Stackify Retrace for Azure monitoring.
Testing in production is easy to set up. In the Azure Portal, choose the testing in production menu option in your App Service.
Here, you can choose the deployment slots that you want to route traffic to (or add new ones) and assign a percentage of traffic to them. That’s it! Now users will be routed to your deployment slots – super powerful!
Deployment slots are awesome and I hope that you give them a chance. You can use them for all sorts of things, but there are also things to keep in mind. Here is the quick overview:
Pros:
Cons:
Start using deployment slots and use them wisely! Let me know what you think in the comments!
Stackify's APM tools are used by thousands of .NET, Java, PHP, Node.js, Python, & Ruby developers all over the world.
Explore Retrace's product features to learn more.
If you would like to be a guest contributor to the Stackify blog please reach out to [email protected]
