The goal of DevOps is to continuously deliver value. Using deployment slots can allow you to do this with zero downtime. In the Azure Portal, in the Azure App Service resource blade for your Web App, you can add a deployment slot by navigating to “Deployment slots,” adding a slot, and giving the slot a name. The deployment slot has its own hostname and is a live app.
Deployment slots are extremely powerful, but care must be taken when you start to integrate them into your DevOps Pipeline. The goal of this post is to focus on best practices and anti-patterns.
Often when I see people using deployment slots in their pipelines, they attempt to swap across environments. This can lead to undesirable results. One example I witnessed had two deployment slots: Dev and QA.
The thinking was they would copy the files to Dev, then swap to QA, and finally swap into Production. On paper, this seems logical. However, rarely are you only dealing with the web application. You also must deploy the database and other dependencies. In the Dev and QA environments, you will also want to run tests such as load and performance tests.
First, we will address testing. Each slot of the web application shares the same resources. Therefore, if you were to run load tests against the QA slot, it would impact the performance of the Production slot as well. Therefore, if you intend to run load tests you need two separate web applications with matching App Service Plans. Matching the level of the App Service Plan is important so that you will be using comparable sized resources.
Second, I want to address restarting an environment deployment. Like many deployment products, Visual Studio Team Services allows you to restart a failed deployment. If you swap deployment slots and deploy a database in your production environment, you may have to restart the deployment if the database fails. When you restart your deployment, you would swap the slots again. This would swap the desired code back out of Production when you restart the deployment.
Rolling back with slots
Many users of slots get excited when they realize they can swap in both directions to “roll back” a change. Although this is true, you need to consider that rarely are you only dealing with the web application. In the cases where you also deployed a database, simply swapping the slots back might leave you in a worse place. You must remember that you are only swapping the web application and not all its dependencies. You must only make changes to your database that do not break the current version of the application. So, to be able to roll back the web application, you must engineer your database deployments to always be at least one version backwards compatible. This will allow you to swap your slots and allow your previous version to function as expected. You may also have to support multiple API versions for web services as well.
Never do anything for the first time in Production
When I use deployment slots, I do so in every environment. If we return to the Dev, QA, and Production example, I would create three different web applications, each with a Stage and Production slot. Notice in the images below that everything I intend to do in production is also done in Dev and QA.
The reason I do this is so each environment is the same. This allows me to verify all my deployment tasks in Dev and QA before I attempt to deploy to Production. If anything is going to fail, it should fail in Dev and/or QA where I can resolve without impacting Production. If you do something for the first time in your Production deployment, the only time you will know if it will work or not is in Production.
For more information on deployment slots see the Azure Documentation.