Zero-downtime deployment with deployment slots in Azure

Time runs faster than Usain Bolt – we all know that. In fact, it passes with a lightning speed and no one wants to waste time on processes and things which can be done quicker.

Imagine that you are a website owner and you want to make a new website which will be much fancier than the one that you have, but you know all the drills that you have during the deployment time – at least two or more hours of downtime period – which can cost you a lot when it comes to your customers.

But, what if you have a tool which will help you forget the downtime period, and even more enable you to do a test in real time, having your customers as the QA team?

And yes, there is such a tool, it is Azure Deployment Slots which gives you zero-downtime and web application with reduced problems!

 

Introduction

 

Azure App Services is a managed hosting platform providing easy-to-use services for deploying and scaling web applications and services and is really useful. There are different types of app services such as: Web Apps, API Apps, Logic apps, Mobile Apps and Function Apps (Azure Functions), and which one we will choose depends on our needs. These apps are incredibly powerful and can literally get us up and running in minutes. They have some quite good features such as: scaling up or out, easy authentication and authorization, hybrid connections, support and troubleshooting etc. There are two types of scaling in Azure, manual and automatic, which one we will use again depends on our needs. These apps share another really important feature which is unique for Azure. It is deployment slots.

 

  • What are Azure Deployment slots, and how can we use them?

 

What are Azure Deployment slots, and how can we use them?

 

Azure deployment slots are the most beautifully crafted feature in Azure App Service. It helps us to deploy different versions on different slots depending on our needs, to swap them, to route a specific percentage of user traffic to one or more of our deployment slots etc.

When we create a web app we already have one deployment slot. That original App Service deployment slot is also called the production slot. If we want to use the benefits of the deployment slots for free, we must use Standard or Premium pricing tire.

When we will deploy our Web App in an Azure App Service it has some URL, e.g. production.website.com and virtual IP address. In Azure App Services, we can easily add an additional deployment slot. Each deployment slot will have different URL and IP address from the others. So, the second one can have this URL userAcceptanceTesting.website.com. Our users would be accessing our original Web App because that is our production environment slot. We can deploy a new version of the Web App into a secondary deployment slot, so we can run the tests on it before it goes live.

swapping slots

When testing on the secondary slot is done, we can swap that with production slot within our same App Service (perform an internal swapping of the IP addresses of both slots). During the swapping process the users will not notice anything and experience no downtime. The swap functionality of the deployment slot takes care of this.

In case there are some problems on the production slot, it lets us to roll back the swap without having to take our application down for maintenance!

It is good to know that deployment slots can copy the configuration (AppSettings and Connectionstrings) of the original App Service or other deployment slots and when we scale a deployment slot (up or out), we also scale all the other slots of the App Service. This is because all slots share the same App Service Plan.

 

  • Different ways to deploy on deployment slots

There are different ways to deploy the code.

  1. To deploy directly from our visual studio
  2. To deploy automatically from our deployment source when we will commit changes on the target branch.

The first approach goes manually. Right click on our project -> Publish -> App Service -> Select Existing (we have already created azure app service) -> Publish -> search for deployment slot on which we want to deploy.

search for deployment slot on which we want to deploy

search for deployment slot on which we want to deploy

The second approach looks for deployment source like: GitHub, Visual Studio Team Services, One Drive etc. It goes automatically. We should have already created an account on some of them, created project on that source, the local project which is connected via Visual Studio with that source. So, when we push the changes on that source it will be replicated automatically on the target Azure deployment slot.

Deploying automatically from our deployment source when we will commit changes on the target branch.

Deploying automatically from our deployment source when we will commit changes on the target branch.

Deploying automatically from our deployment source when we will commit changes on the target branch.

Deploying automatically from our deployment source when we will commit changes on the target branch.

 

  • Redirect some % of user traffic to one or more of our deployment slots

Redirect some % of user traffic to one or more of our deployment slots

Testing on UAT deployment slot and swapping that slot with production slot is a good feature, but what will happen if there is a big web application and we miss something to test? There are cases when the customers can make scenarios which the QA team might miss out. It will be good if we get it before our web application goes to production.

Another important feature of the deployment slots is the ability to route a specific percentage of user traffic to one or more of our deployment slots in order to test a new version of our web application. It is named “testing in production”.

To control everything, we should monitor via Azure monitoring.

monitor via Azure monitoring

 

Conclusion

 

To sum up, the deployment slots help us verify the new version of our web application separately from the old version that is in production.  Swapping two slots on Azure is quite easy, fast and it gives us zero-downtime deployments, which as a feature is quite important. No more spending nights in deploying the new version of our web application, we can deploy it during the day. We will not lose any customer, because our web application will not have downtime. The bugs will be reduced in production, thanks to the feature “testing in production”, meaning that some of our customers will be redirected to our web application which is on UAT or other environment. In that case we will test our new version of the web application with real scenarios.