Best practice for minimizing downtime when deploying Azure Web Apps

Question

I have an App Service Plan, and in this plan I have deployed 5 components of my solution as Web Apps. I use 'Release Management' in Azure DevOps to deploy code to these apps.

To minimise downtime during deployment, I deploy to staging slots first, and then swop the staging slots into production slots to complete deployment.

I have configured App Service Warmup (as detailed here) to call an endpoint that will 'warm up' the application during the slot swapping process.

This seems to work, but I have two issues:

1. Even though the warmup has run, the first request made to the app after slot swapping takes a long time. I suspect that this is due to the production slot having a 'sticky / slot settings', which as I understand it necessitates an app restart. To test this, I removed the slot settings, but the delay is still there.

2. The applications are dependent on each other, and the slot swapping (even though kicked off in parallel in Azure DevOps), is not guaranteed to complete at the same time, which means that it is possible for newer code to be interacting with old code. While we can engineer around this, this is not optimal.

From my investigations so far, the only way I can think of to work around these issues is to spin up a second app service plan, and configure traffic manager to sit in front of the two service plans. When deploying, I will prioritise one of the service plans while I deploy to the other service plan, and once that is complete divert traffic to the newly deployed service plan while upgrading the other, and then balancing the traffic between the two again once both are on the same code level.

What is the current 'best practice' for zero downtime deployments when using WebApps in Azure?

Is the duplicated service plan with traffic manager a viable option, and if not, what would you suggest?

Answer 1

Follow these more best practice recommendation.

SWAP BASED ON THE STATUS CODE

During the swap operation the site in the staging slot is warmed up by making an HTTP request to its root directory. More detailed explanation of that process is available at How to warm up Azure Web App during deployment slots swap.

By default the swap will proceed as long as the site responds with any status code. However, if you prefer the swap to not proceed if the application fails to warm up then you can configure it by using these app settings:

• WEBSITE_SWAP_WARMUP_PING_PATH: The path to make the warm up request to. Set this to a URL path that begins with a slash as the value. For example, “/warmup.php”. The default value is /.

• WEBSITE_SWAP_WARMUP_PING_STATUSES:Expected HTTP response codes for the warm-up operation. Set this to a comma-separated list of HTTP status codes. For example: “200,202” . If the returned status code is not in the list, the swap operation will not complete. By default, all response codes are valid.

MINIMIZE RANDOM COLD STARTS

• WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG: setting this to “1” will prevent web app’s worker process and app domain from recycling when the App Service’s storage infrastructure gets reconfigured.

https://ruslany.net/2019/06/azure-app-service-deployment-slots-tips-and-tricks/#prevent-cold-start

CONTROL SLOT-STICKY CONFIGURATION

If however for any reason you need to revert to the old behavior of swapping these settings then you can add the app setting WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS to every slot of the app and set its value to “0” or “false”.

https://ruslany.net/2019/06/azure-app-service-deployment-slots-tips-and-tricks/#slot-sticky-config