Should I stop an Azure App Service during an update?
There are (5) options for safe-deployment (atomic updates) to Azure Web Apps. Here is my preferred order ranked by priority and feature richness:
- Run-from-Package + ZipDeploy (makes site read-only)
- ZipDeploy (using kudu REST api - automatically takes site offline)
- Azure CLI (az webapp)
- msdeploy (
-enableRule:AppOffline, or stop/start site to enforce atomicity) - 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
What we have done mostly is:
- Stop staging slot
- Deploy to slot
- Start slot
- Swap staging to production
- 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.
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 ð
