Azure DevOps: automate App Service slot swaps in your VSTS release pipeline

Choosing Azure App Services to host a web application means that you are using a managed platform and therefore have less responsibilities (such as OS updates and patching). Another specific feature that can be extremely useful is slots. Slots allow you to deploy your application to a separate live app service, warm it up and make sure it’s ready for use in production, and then swap the slots to provide seamless traffic redirection.

You can slot swap manually (in the portal or command line) or you can automate the slot swap with Auto-swap or in a script.

I’ve been asked a few times recently about how to do this as part of a VSTS release pipeline and so I thought I’d outline my approach here.

Scenario

Let’s keep it pretty simple and say that the release pipeline for a web application is going to cover deploying to a Dev environment, then QA, then Staging and finally Production. Human approvals will be needed at points, but especially in approving the final release into Production. We will use slots so that the staging environment can be warmed-up, reviewed and then final approval triggers the slot swap.

VSTS Release Pipeline

We’ll create a release pipeline that has Dev, QA and Production:

Why no Staging? The Production environment will have both a staging and production slot and we’ll manage the transition between the two in that environment.

Why are Dev and QA separated? To reflect the app service separation. You could have Dev and QA as additional slots in production (you can have up to 15) but it makes sense to keep the production and non-production environments apart. This allows you to choose different hosting plans (size/scaling/cost) and also isolates impact, such as load testing in the QA environment.

Could you have Dev and Test as separate slots in a single “non-production” environment? Yes, you could. I’ve chosen to split them so they have potentially different lifecycles but that’s more subjective.

Configuring slot swaps in Production

The Dev and QA environments orchestrate whatever flow you want in those environments (e.g. provision using ARM, deploy, run functional tests, run load tests etc.), and in this example don’t have any slot specific activity. Therefore let’s take a look at the production environment tasks:

(I’ve kept this to a minimum to keep it clearer, so no provisioning, running scripts or other activities.)

First deploy the web application to the staging slot in the production environment using the Azure App Service Deploy task:

Check the Deploy to slot option in the standard task, and then choose the Slot (I called the slot “staging” but you can use any name).

Next I’ve added an Agentless phase as it’s not going to delegate any actions to an agent, and added a Manual Intervention task. This causes the flow to pause until the manual intervention is completed by the specified approvers (groups and/or individuals). If it’s approved then it carries on, if it’s rejected (or times out and therefore is rejected) then the flow stops. In this case that works for me as I want the staging environment to be manually verified and then signed off as ok for final release to production. If it gets rejected then it never gets promoted from staging to production.

Finally, if the staging slot has been manually verified and is ready to be used, then we can initiate the actual slot swap (in an agent phase) using the Azure App Service Manage task:

The staging and production slots will then be swapped over, leaving the old production version in the staging app and the latest version in the production slot.

This flow supports the actual slot swaps being automated, but with manual approval. A nice side effect of the slot swap is that should there be a problem, the slot swap can be reversed to redeploy (rollback) the old version of the app now in the staging slot.

Comments

• Anonymous
  September 18, 2018
  Thanks for this article! It would be nice to finish the story on how to get the lastest code to production to than swap back the slots.
  • Anonymous
    September 18, 2018
    Hi Andreas,Thanks, good idea, I'll update this soon to add in how to swap the slots back again when a rollback is needed.
    • Anonymous
      September 18, 2018
      Hi gdavi, thanks for replying so fast. I wasn't talking about a rollback scenario. Maybe I didn't get something right, please let me explain my understanding.1. Swap staging and production so latest release with zero download is available2. Staging is the currently used slot to answer all requests, while production still is on older code3. How to update production in Azure DevOps steps and how to change back to production, so the next release can rollout.
      • Anonymous
        September 19, 2018
        Hi Andreas,My apologies, I misunderstood. Yes, it would be useful to cover that flow, so I will do as soon as I get a chance.Thanks, Giles