Some time ago I had a blog post describing how to warm up an Azure Web App during deployment slots swap. In that post I explained the sequence of actions that happens during the swap. One important point in that explanation is that if a site has any app settings or connection strings that are marked as “Slot” then during slot swap those settings are read from target (e.g. Production) slot and applied to the site in the staging slot. That causes the restart of the site’s worker process so that those changes take effect and become visible as process environment variable.

The restart of the worker process is OK for the majority of the swaps. But sometimes it would be useful to pause right after the production settings were applied on the staging slot and before the actual swap of host names happens. Recently Azure Web Apps team has released a “Swap with Preview” feature that supports that use case. That feature will give you a chance to verify that the web site in the staging slot works fine with production settings. Also this will allow you to warm up/initialize the site in any way you want. For example you can generate some load on that site so that its cache is completely pre-populated. After you are satisfied with how the site works in staging slot you can complete the swap so that the site is moved to production slot and starts taking on production traffic. The site’s worker process will not be restarted during that step, which means that the worker process in production slot is exactly what you have tested in staging slot.

Note that currently this feature is in Preview meaning that it is ready to be tried but not yet recommended for use with business-critical applications.

To demonstrate how Swap with Preview works I’ve created a site and added a “Slot” setting to it with name “SlotName” and value “Production“. Also I added a “Slot” connection string with value “ProductionConnectionString“.

Then I’ve created a staging deployment slot for this site and added a “Slot” setting to it with name “SlotName” and value “Staging“. Also I added a “Slot” connection string with value “StagingConnectionString“.

Then I have deployed the following ASP.NET code to both sites in production and staging slots. The code reads the environment variables where the app setting values are stored. Also it reads the current process id which changes every time the site gets restarted.

If I browse to the production and staging slots I can see the process ID, app settings and connection strings:

Production slot:

Staging slot:

Now let’s assume that I have deployed a new version of an app into a staging slot and want to swap it into production. I use the “Swap” action which gives me a choice of doing a normal Swap or “Swap with Preview”. I chose “Swap with Preview” and click OK.

After the operation completes let’s browse to the staging slot:

Notice that the Process ID has changed, meaning that the worker process has restarted. Also the SlotName and ConnectionString now contain the values from the production slot. Basically the site now has all the settings that it would have in production slot except that it is still in the staging slot and does not receive any production traffic. This gives me an opportunity to verify how the new version of my app behaves with production settings. Also it lets me hit all the important URL paths on my app to make sure they are properly warmed up.

IMPORTANT: While the site is in this “swap pending” state it is not possible to make any changes to connection strings and app settings of both slots involved in the swap.

From here I have two options. If I am happy with how my new app version works with production settings I can complete the swap by using “Complete Swap” action and then choosing “Complete Swap” from the drop down list:

if I browse to the production slot after the swap completes I can see that it now has the new version of my app and the Process ID is the same, meaning that the worker process has not restarted.

If however I find that the new version of my app in staging slot does not work very well with production settings I can chose “Cancel Swap” action, which will reset the settings on my staging slot.

This example demonstrates how to perform deployment slot swap while pausing after target slot settings have been applied to the current slot and before the swap completes. During that paused state you can prepare application for taking on production traffic so that when you complete the swap you have exact same application in production slot without any restarts.

With the addition of the “Swap with preview” capability there are now three options for how to perform deployment slot swaps. They range from fully manual to fully automated and you can choose any of them depending on how confident you feel about new bits you deploy:

Swap with preview – this is the option which gives you most control over the swap process. It allows you to fully verify the new version of your app before it is swapped into production and it helps to avoid restarts during the swap.

Regular swap – this is the most common swap option, where the application get automatically warmed up prior to the swap. Application in the staging slot may get restarted prior to the swap.

Auto-swap – this is the fully automated option where swap operation is triggered as soon as the new content is deployed to a staging slot.

2 Responses to “Azure Web App Deployment Slot Swap with Preview”

Sorry if this is old but I noticed recently after I’d been doing quite a bit of slot swapping that it seems the entire file system of the app service gets swapped – including log files! Now I understand that there may be other locations I can write logs to, but my basic principle with writing logs is to stick to whatever is least likely to fail – i.e. the local file system. Are there any recommendations as to where we might be able to reliably write logs to that don’t get swapped? I’m using log4net so hopefully it’s just a config file to define a new log appender.

great article!
You say that a root call is made after the deployment.
In my case, the root is just a blank page en application_start. Which is good, the preloader starts warming up. However, this doesn’t check any dependecies.
I can force the root call to go to a ‘healtcheck-controller’ and check all dependencies to work. However, what I cannot find is; if the reqests returns a 500-status. Will the swap not take place? If so, that would be great
If not; do you have any other ideas?