Utilizing Azure Application Deployment Slots with the Visual Studio Team Services build and deployment system is quite simple.

Set Up Deployment Slots

The first step is to create your deployment slots for your application. You do this in your Azure Portal. Open the dashboard to your App Service application’s options. About halfway down the menu options that appear for your app you will see “Deployment slots”. Select this option.

Click “Add Slot” and give your deployment slot a name. It also asks you to select whether or not to copy the existing configuration options from an existing slot. This will depend on your preferred deployment process. Some people let their deployment instance use all the same configuration options. I usually use the existing database connections, if any, but will alter any message queues, blob storage, table storage, and anything else that can trigger functionality on the back end, I point these to their respective testing versions so I don’t mess with production data unexpectedly. This is especially true for message queues, I feel. I want to be able to control the testing of the staging slot and not have it kick off unexpectedly if some production message gets through.

Either way, I generally go ahead and copy the prod settings since I haven’t deployed any code yet. Then I go into the slot settings and alter what I need to alter for the deployment slot.

Once your slot is created, you’ll see it appear in the list to the right. Click on the name of the slot you created to open the app menu and settings for that slot. It’s important to remember that a deployment slot is a complete instance of your web application running side by side with your production application. It will count as a complete application in Azure so you will be charged for its existence the same way as your prod instance.

Another thing you need to understand. When Azure swaps between your deployment slots, what it is effectively doing is swapping where traffic is being routed and renames the instances. So prod becomes your staging slot and staging becomes your prod slot. What you do here can be dangerous, so check and double check everything as you work through your settings for the deployment slot to make sure they are set correctly.

Under your deployment slot you can select “Application Settings”. You should see all the settings that have been copied over. The key thing for the settings you want to change is the “Slot setting” checkbox. For each setting that you change to a deployment slot version, check this box. What this checkbox means is that the setting with this flag will remain with whatever instance is currently given this slot name. If you change your database connection string to point to test, that test string will always be present in whichever instance is currently your deployment instance. When you swap slots, Azure will swap the marked settings so that the instance that is now your deployment instance will now have these settings.

Once you mark any settings with the “Slot setting” flag that you need to, go into your production instance and mark those same settings with that flag. This will ensure prod always has the prod settings and deployment always has the deployment settings. I know I really hammer on that point. But for those new to the process, it’s the most likely spot to get tripped up and screw something up in your production app.

Any time you want to want to swap your deployment slot with production, it’s simple. From the deployment slot instance menu, select “Overview” if you’re not already there. At the top of the Overview page, you’ll see a menu item between “Stop” and “Restart” that says “Swap”. Click that button. In the Swap menu, generally the defaults are already correct, but make sure the Type says “Swap”, the Source lists your deployment slot and Destination lists your production instance. If that’s all correct, click “OK” and it will proceed to make the change. Generally it takes only a couple seconds to complete.

That’s all for the Azure Portal for now, so let’s go over to VSTS.

Create/Update Your Build Process

If you already have a build and deployment process in Visual Studio Team Services, great! You only need to make a couple minor changes. If you’re creating a build from scratch, it’s pretty straightforward and I will skim the highlights of the first pieces as that’s beyond the scope of this article. Generally, for basic deployments, your first two steps will be NuGet Installer and Visual Studio Build.

Now is where the changes happen. The next step will be your Azure App Service Deploy step. Add it to the bottom of your build steps if you don’t already have one. If you already have this step, you only need to click the “Deploy to slot” checkbox and change the “Slot” entry to point to your deployment slot in Azure instead of your production slot. Everything else stays the same.

If you’re adding this step new, I’ll walk through the options:

  • Display Name: Enter whatever you like here
  • Azure Subscription: Select the Azure subscription that holds the application in question. If you haven’t yet set up your connection to Azure from VSTS, click “Manage” to the right and set up that link
  • App Service name: Select the app service you are deploying to
  • Click the “Deploy to slot” checkbox to allow you to deploy to a slot other than the main one
  • Resource group: Select the Resource group in Azure that holds the application you selected in App Service name.
  • Slot: Select you deployment slot here
  • Package or Folder: Select the output directory of your previous Visual Studio Build step. For ASP.NET apps this is generally just the base folder of the application
  • Under Additional Deployment Options I usually double check that “Publish using Web Deploy” is selected, “Remove Additional Files…” is selected, and “Take App Offline” is selected. These are preferences that apply to how I like to deploy and you can select whatever works for you

That’s it for the Deploy step. Now you have two options. If you want it to go ahead and swap the slots so long as the build and deploy were successful, then proceed to the final step. If, instead, you want to go through a manual testing and approval process of some sort, stop here. Once you’re satisfied with the deployment slot instance, you can swap the instances from within the Azure Portal.

If you want to have VSTS do the swap automatically, we need to add one last step. Add the Azure App Service Manage build step to your build. Here’s a rundown of the settings:

  • Display Name: Whatever you like
  • Azure Subscription: Same as above
  • Action: Select “Swap Slots”
  • App Service name: Same as above
  • Resource Group: Same as above
  • Source Slot: Select the name of your deployment slot from the dropdown
  • Check the box marked “Swap with Production”

And that’s it! It’s fairly simple to set up with just a tricky part in your app settings. Now whenever VSTS runs a build and deployment, it will push the code