![\"2017-04-10_8-02-58\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/6\/2019\/05\/2017-04-10_8-02-58.png\")
<\/a><\/p>\nDeployment slots are extremely powerful, but care must be taken when you start to integrate them into your DevOps Pipeline.\u00a0 The goal of this post is to focus on best practices and anti-patterns.<\/p>\n
Often when I see people using deployment slots in their pipelines, they attempt to swap across environments. This can lead to undesirable results.\u00a0 One example I witnessed had two deployment slots: Dev and QA.<\/p>\n
The thinking was they would copy the files to Dev, then swap to QA, and finally swap into Production.\u00a0 On paper, this seems logical. However, rarely are you only dealing with the web application.\u00a0 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.<\/p>\n 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.<\/p>\n 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\u00a0and deploy a database in your production environment, you may have to restart the deployment if the database fails.\u00a0 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.<\/p>\n Rolling back with slots <\/strong><\/p>\n Many users of slots get excited when they realize they can swap in both directions to \u201croll back\u201d a change.\u00a0 Although this is true,\u00a0you need to consider that\u00a0rarely 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.\u00a0 You must only make changes to your database that\u00a0do not break the current version of the application.\u00a0So, 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.<\/p>\n Never do anything for the first time in Production<\/strong><\/p>\n 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.\u00a0 Notice in the images below that everything I intend to do in production is also done in Dev and QA.<\/p>\n 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.<\/p>\n<\/a><\/p>\n<\/a><\/a> <\/a><\/p>\n