Should I stop an Azure App Service during an update?

user_5819671 0
Viewed 1836

I am updating my Azure App Service from Azure DevOps. Currently, my release is like this:

  1. Stop the App Service,
  2. Update the App Service, and
  3. Start the App Service.

My question is whether it reasonable to stop the App Service during the update? When I select a release template from Azure DevOps for Azure App Service, there are't any stop/start steps, only the update step. So I am wondering if the stop/start is even needed?

azure-web-app-service azure-devops azure
4 Answers

What we have done mostly is:

  1. Stop staging slot
  2. Deploy to slot
  3. Start slot
  4. Swap staging to production
  5. Stop staging slot

Martin's suggestion on Take app offline is also a good one!

We prefer to deploy to slots and then swap so we incur minimal impact to production and can also rollback easily. Stopping/taking app offline can prevent file locking issues.

user_16589060

It probably depends on your app. If you don't have any issues when you just update your app (such as the a file is in use issue) you can consider to use the Take App Offline flag which will place an app_offline.htm file in the root directory of the App Service during the update (then it will be removed). This way user will recognize that something is happening with the app.

However, I often ended up doing the same like you: Stop, Update, Start

enter image description here

user_11634230

There are (5) options for safe-deployment (atomic updates) to Azure Web Apps. Here is my preferred order ranked by priority and feature richness:

  1. Run-from-Package + ZipDeploy (makes site read-only)
  2. ZipDeploy (using kudu REST api - automatically takes site offline)
  3. Azure CLI (az webapp)
  4. msdeploy (-enableRule:AppOffline, or stop/start site to enforce atomicity)
  5. FTP (using publish profile, make sure to upload appoffline.htm)

There are numerous other deployment options like cloud sync, github continuous, local git, etc - but they are all built upon Kudu APIs (as is Azure CLI).

Note: If you're using Azure DevOps - it's supports nearly all these options - leverage the Azure App Service Deploy task

user_1756790

Agree with both Martin and juunas. If you want to deploy without impacting users then you need to use the slot swap approach. juunas brings up the great point of easily rolling back too. Our approach includes another slot we call "hotfix". This adds a few benefits:

  1. Having an environment with production configs so that you can optionally do additional testing before actually doing the swap.

  2. Roll back in prod even when devs have already deployed into a staging environment.

  3. Allows you to test bugs in the current and previous versions of the code. Helpful when someone says "well it worked before this deployment"...

This is what it looks like.

enter image description here

user_12390120
Related