From how I understand it, the only reason a staging site would require restart is if there exists app settings or connection strings configured as slot settings.
Although this doesn't always seem to be true. One of our applications will restart regardless. I have used Powershell cmdlets to be sure that there are no slot settings "hidden" from the Portal (because apparently this is a thing).
What other factors can determine whether the staging site will be restarted during a swap?
(I posted this on the kudu GitHub repository, but haven't heard back)
In response to Byron's answer:
I have done some pretty thorough testing (see my testing repo for this) and I am able to perform slot swapping (with and without Preview) without either production or staging slot restarting. This is obviously with no slot settings configured on the Web Apps.
Does this mean that restarts are not guaranteed? The issue I'm raising here is that if no restart occurs will IIS' Application Initialisation module still ensure that the application has indeed warmed up (as these things could take a couple of minutes)?
You are right that the staging slot will always be restarted prior to the swap if there are app settings or connection strings marked as slot settings. There are a few other conditions that cause restart, for example when continuous deployment is enabled as described here http://ruslany.net/2014/03/azure-web-sites-continuous-deployment-with-staged-publishing/. Other reason for restart is when site authentication is enabled on either production or the staging slots.
If there is no restart then appinit module will not be re-executed during the swap because it only runs when the worker process is initialized. If you want to ensure that there is always restart then you can just create some dummy app setting and mark it as a slot setting.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With