Time runs faster than Usain Bolt – we all know that. In fact, it passes with lightning speed and no one wants to waste time on processes and things that can be done quickly.
Imagine that you are a website owner and you want to make a new website that 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 that 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?
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.
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.
- To deploy directly from our visual studio
- 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.
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.
- 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.
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.
