We have a site hosted as a Azure Web App, we deploy to a deploy slot and swap the slots with preview using powershell scripts. (Swap-AzureRmWebAppSlot with preview)
I’ve been trying to add some application initialization code by adding some endpoints to the applicationInitialization section in the web.config. The requests are being made (can see that in the logs) however it looks like octopus just continues with the process without waiting for those requests to finish.
One of the requests only returns after 5 minutes due to a Thread.Sleep, but as Octopus has continued already it defeats the purpose of the applicationInitialization.
Has anyone experienced something similar? Or maybe you know of an example where applicationInitialization is working properly?
We found an interesting article here which suggests that the warmup logic is honoured by Production slots only (not Staging slots). There is also some feedback on Azure’s UserVoice about adding application initialization/warmup support for scaling up/down that may be of interest. Another older article here suggests that the swap operation causes the app host process to restart which then forces the application initialisation to occur again, so the delay might be unavoidable … sorry for all the links, but we found them all interesting
In terms of workarounds from an Octopus point-of-view, we were wondering if you could move the application initialization work out into an Octopus script step, so:
deploy to your Azure deploy slot
run script to execute any initialization you need (where your script is forced to wait until those request return successfully)
run script to swap the slot
Similarly, if your application has an endpoint that you could make a request to (to confirm that the application initialization/warm-up logic has completed), you could write some PowerShell that executes (before your swap slot script) to confirm that the app has finished initializing, then proceed with the swap. You could make it resilient with a while loop and a start-sleep command so it keeps checking until it receives a 200/success response from your application (with a maximum number of retries as a bail-out).
In terms of how Octopus deploys to your Azure Web App, we use Microsoft’s WebDeploy to sync your package to your app service. The code is open-source in our Calamari library and can be seen here. We checked, but couldn’t see any additional options available on that DeploymentManager class that would help instruct Azure to wait for application initialization.
It may be worth getting in touch with Azure’s support to see if they have any recommendations.
