Any guidance on Pulumi deployment of Azure app service with staging slot?

[Olehoyer-3shape]

Hi,
I am looking for guidance using Pulumi for deployment of an Azure App Service with a staging slot using the Pulumi AzureNative library.

Some context/requirements
The pulumi stack must be able to deploy to multiple environment as we progress through the deployment pipeline. Some of the environments do not need a staging slot. Therefore the stack should also be able to deploy to "production-slot" only, if staging is not configured.

Currently, I have a Pulumi stack where I am using an Pulumi.AzureNative.Web.WebApp object to deploy to production slot and a Pulumi.AzureNative.Web.WebAppSlot object to deploy to a staging slot.

var app = new WebApp("myApp",
                new WebAppArgs
                {
                   ...
                   SiteConfig = new SiteConfigArgs
                    {
                        AppSettings = {
                            new NameValuePairArgs{
                                Name = "WEBSITE_RUN_FROM_PACKAGE",
                                Value = productionPackageUrl,
                            },
                     ...
                   }
                }

var slot = new WebAppSlot("staging",
                new WebAppSlotArgs
                {
                    Name = app.Name,
                    ...
                                       SiteConfig = new SiteConfigArgs
                    {
                        AppSettings = {
                            new NameValuePairArgs{
                                Name = "WEBSITE_RUN_FROM_PACKAGE",
                                Value = stagingPackageUrl,
                            },
                     ...
                     }
                }

I am using the WEBSITE_RUN_FROM_PACKAGE appSetting and the Pulumi.AzureNative.Storage object for uploading the zipped package to Azure blob storage (as in your sample pulumi code).
After the first deployment to both production slot and staging slot I need only changes in staging slot and no changes to Production object. Production is upgraded during a subsequent swap of staging and production.
To get around the issue of "not making changes to production" I am using the Get method on the WebApp object. This is how I have been able to manage that Pulumi does not to delete Production slot.

Can you recommend better ways to have the production slot untouched after first deployment?

Another issue is that after my first deployment (pulumi up) it does not correctly handles the appsetting for the WEBSITE_RUN_FROM_PACKAGE as it has been swapped to production but is still managed as state in the pulumi state file (note that I do the staging-to-production swap from script - not from Pulumi - we cannot do automatic swap do to proces requirements).
In the event that the application package has been upgraded, we must upgrade to a new version of the Blob object in pulumi. Currently Pulumi will replace the package in my stack for the stacking slot. But this is the package being is used in production.
It would be much better if I couldt append a new Blob using Pulumi and then point the WebApp to the new BlobUrl. How can I do that in Pulumi?

[zdenek-jelinek]

This has been open for years and I'm not sure if the question is still relevant but I was just working on this topic and this question is one of the reasonable web search results so I figured out I'd share what I settled with. The AI-generated pages that are part of the results do describe some forms of swap but I don't really think it's zero-downtime. There is also an official documentation how to do it using ARM templates but I haven't tested any of it because I have concluded that swapping from within pulumi only is not practical.

The swap is typically executed during a deployment which features some preparatory steps. In my case, I want the following sequence to happen:

1. Update Azure resources
2. Apply database migrations
3. Deploy new binary artifact to App Service staging slot
4. Swap App Service staging slot with production slot

The order is significant as I don't want to apply database migrations when the database was not created in the resource update step yet. The App Service and the artifact deployed there is a similar story. This is why I think it's a job for a deployment pipeline, not for pulumi alone and why I discarded all the AI answers that only consider pulumi.

Another constraint is that the infrastructure setup must not modify the App Service production slot in any way to avoid restarts. So for example, to change e.g. some environment settings, they are first applied to the staging slot and then swapped with the production slot. So the process is indirect - a resource needs updating but the path is to update a different resource and then exchange them. Pulumi, as far as I understand it, works with a model where resource has state A and transitions to state B through direct updates so this cannot be done. Even though I would enjoy being proven wrong here, it wouldn't change the sequence prerequisite steps needed prior to deploying an artifact.

What I ended up with is a setup in two parts:

First, I have an App Service with a staging slot. The staging slot has all the changing configuration whereas the WebApp itself has SiteConfig property ignored. As a result, pulumi only applies changes to the staging slot and ignores everything in the production slot.

Running the deployment steps listed above ends with staging slot containing the original production slot artifact and configuration. This means that the staging slot has now diverged from pulumi state and we need to refresh it, which is the second part. This can either be done with the next deployment or in the current one after the swap. I am so far running it at the start of the next deployment. I don't update the deployment artifact in staging slot either so that I can roll back easily if needed.

Technically, the second part means running pulumi refresh with a wildcard taget (--target **azure-native:web:WebAppSlot::<my-slot-name>) to update the staging slot state. The wildcard has the benefit of not failing when zero slots are found due to deployment to new environment (remember that the refresh runs before applying resource updates). IIRC, sticky settings are set up outside of the slot in a separate resource so they may need to be targeted in the refresh as well. I don't have any such settings so I can't really tell.