App Service Deployment Slots and Swapping

Deployment slots are live, fully functional instances of your App Service app that run in the same App Service Plan but with their own hostnames, settings, and code. Each slot is essentially a separate deployment environment that shares the same underlying compute resources. The primary slot is called the 'production' slot, and you can create additional slots (e.g., 'staging', 'testing') for testing new versions of your app before making them live.

The main purpose of deployment slots is to enable zero-downtime deployments. By deploying your new code to a staging slot and then swapping it with the production slot, you avoid any downtime during deployment. Additionally, you can route a percentage of traffic to a specific slot for A/B testing or canary releases. The exam focuses on:

When you initiate a swap between two slots (e.g., staging to production), Azure performs the following steps:

Using Azure CLI:

# Create a new slot
az webapp deployment slot create --name MyApp --resource-group MyRG --slot staging

# List slots
az webapp deployment slot list --name MyApp --resource-group MyRG --output table

# Swap slots
az webapp deployment slot swap --name MyApp --resource-group MyRG --slot staging --target-slot production

# Configure auto-swap
az webapp deployment slot auto-swap --name MyApp --resource-group MyRG --slot staging

# Set sticky settings (slot-specific)
az webapp config appsettings set --name MyApp --resource-group MyRG --slot staging --settings MySetting=MyValue --slot-settings

# Route traffic to a slot
az webapp traffic-routing set --name MyApp --resource-group MyRG --distribution staging=10 production=90

Using Azure PowerShell:

# Create a slot
New-AzWebAppSlot -ResourceGroupName MyRG -Name MyApp -Slot staging

# Swap slots
Switch-AzWebAppSlot -ResourceGroupName MyRG -Name MyApp -SourceSlotName staging -DestinationSlotName production

# Set sticky settings
Set-AzWebAppSlot -ResourceGroupName MyRG -Name MyApp -Slot staging -AppSettings @{"MySetting"="MyValue"} -SlotSettings @{"MyStickySetting"="StickyValue"}

A large e-commerce company deploys updates multiple times per day. They use a staging slot for each deployment. The production slot connects to a live database, while the staging slot connects to a replica database. They mark the database connection string as a slot setting to prevent accidental data corruption. After deploying to staging and running automated tests, they swap. If the swap causes errors (e.g., a broken checkout page), they swap back immediately. This setup allows zero-downtime deployments and quick rollbacks. In production, they also route 5% of traffic to the staging slot for canary testing before full swap. This is configured via the 'Traffic Routing' blade. They monitor error rates and performance metrics to decide when to perform the full swap.

A SaaS provider hosts multiple tenants in a single App Service app, using slot-specific settings to differentiate environments. They have a 'dev' slot, 'test' slot, and 'staging' slot. Each slot has its own set of connection strings and app settings that are sticky. They use auto-swap for the staging slot: whenever a new build is deployed to staging via CI/CD, Azure automatically swaps it with production after a successful deployment. This eliminates manual intervention. They also use the WEBSITE_WARMUP_PATH setting to ensure the application's cache is warmed up before receiving traffic. A common misconfiguration is forgetting to mark the tenant-specific settings as sticky, causing the wrong tenant to receive production data after a swap. They learned this the hard way when a swap caused a tenant to see another tenant's data.

A government agency requires that all changes go through a formal approval process. They use 'Swap with preview' to allow compliance officers to validate the staging slot before the swap completes. The preview phase shows the staging slot with production settings (but no traffic), allowing them to check functionality. After approval, the swap completes. They also have a custom domain bound to the production slot, and they ensure the SSL certificate is also slot-specific. During an audit, they demonstrated that no downtime occurred during deployments. Misconfiguration of slot settings once caused a security breach where a test API key was exposed in production; they now enforce that all sensitive settings are marked as slot settings.