Azure App Service deployment slots are powerful features that enable you to deploy and test applications in separate environments before swapping them to production. Deployment slots are live apps with their own hostnames, available in Standard, Premium, and Isolated App Service plans.
To configur…Azure App Service deployment slots are powerful features that enable you to deploy and test applications in separate environments before swapping them to production. Deployment slots are live apps with their own hostnames, available in Standard, Premium, and Isolated App Service plans.
To configure deployment slots, navigate to your App Service in the Azure Portal and select 'Deployment slots' under the Deployment section. Click 'Add Slot' to create a new slot, providing a name and optionally cloning settings from an existing slot.
Each deployment slot maintains its own configuration settings. You can designate settings as 'slot-specific' (sticky) or 'swappable'. Sticky settings remain with the slot during swaps, while swappable settings move with the application code. Common sticky settings include connection strings for staging databases, debugging configurations, and environment-specific app settings.
The swap operation exchanges the roles of source and target slots. Before performing a swap, Azure warms up the source slot by applying target slot settings, ensuring minimal downtime. You can perform manual swaps or configure auto-swap for continuous deployment scenarios.
Key configuration steps include:
1. Creating slots with meaningful names like 'staging' or 'testing'
2. Configuring slot-specific application settings using the 'Deployment slot setting' checkbox
3. Setting up traffic routing to gradually shift user traffic between slots using percentage-based routing
4. Implementing swap with preview (multi-phase swap) for validation before completing the swap
Best practices involve using staging slots to validate changes, implementing health checks to verify application readiness, and utilizing slot-specific connection strings to prevent staging environments from accessing production data.
Deployment slots support various deployment methods including Git, Azure DevOps, GitHub Actions, and ZIP deploy. You can also use Azure CLI or PowerShell commands like 'az webapp deployment slot swap' for automation in CI/CD pipelines, making deployment slots essential for achieving zero-downtime deployments and robust release management.
Configure Deployment Slots for App Service
Why Deployment Slots Are Important
Deployment slots are a powerful feature of Azure App Service that enable zero-downtime deployments and safe release practices. They allow you to deploy and test new versions of your application in a production-like environment before swapping them into production. This reduces risk, enables quick rollbacks, and supports modern DevOps practices like blue-green deployments and A/B testing.
What Are Deployment Slots?
Deployment slots are live apps with their own hostnames that belong to the same App Service plan. Each slot represents a separate instance of your application. The production slot is your main app, while additional slots (staging, testing, development) can be created for various purposes.
Key characteristics include: - Each slot has its own URL (e.g., myapp-staging.azurewebsites.net) - Slots share the same App Service plan resources - Available on Standard, Premium, and Isolated tiers - Standard tier allows up to 5 slots; Premium and Isolated allow up to 20 slots
How Deployment Slots Work
Slot Swapping: When you swap slots, Azure performs the following: 1. Applies settings from the target slot to all instances of the source slot 2. Waits for every instance to restart and warm up 3. Swaps the virtual IP addresses between slots 4. The swap is atomic and causes no downtime
Slot Settings: Settings can be configured as slot-specific (sticky) or swappable: - Sticky settings stay with the slot (connection strings marked as slot settings, custom domain bindings) - Swappable settings move with the app during swap
Auto Swap: Enables automatic swapping from a source slot to production when code is pushed to that slot. This is useful for continuous deployment scenarios.
Swap with Preview (Multi-phase Swap): Allows you to validate the app with destination slot settings before completing the swap. You can cancel if issues are detected.
Common Use Cases
- Staging and Validation: Deploy to a staging slot, test thoroughly, then swap to production - Blue-Green Deployments: Maintain two identical environments and swap between them - Rollback: If issues occur after swap, simply swap back to restore the previous version - A/B Testing: Route a percentage of traffic to different slots for testing
Traffic Routing
You can route a percentage of production traffic to other slots for testing purposes. This is configured in the deployment slots blade and allows gradual rollout of new features.
Exam Tips: Answering Questions on Configure Deployment Slots
1. Remember the tier requirements: Deployment slots require Standard tier or higher. If a question mentions Free or Basic tier, slots are not available.
2. Understand sticky vs swappable settings: Know that connection strings and app settings can be marked as slot-specific. Questions often test whether settings will swap or stay.
3. Know the slot limits: Standard tier = 5 slots maximum; Premium/Isolated = 20 slots maximum.
4. Swap behavior: Remember that swapping exchanges the virtual IP addresses, making it instantaneous with no cold start for the production slot.
5. Auto Swap limitations: Auto Swap is not supported on Linux App Service plans. This is a common exam trap.
6. Swap with Preview: When questions mention validating configuration before completing deployment, think of multi-phase swap or swap with preview.
7. Traffic routing percentage: Questions about gradually testing new versions with a subset of users point to traffic routing between slots.
8. Rollback scenarios: If asked about the fastest way to revert a problematic deployment, the answer is typically swapping slots back.
9. Warm-up: Azure warms up the source slot before swapping. Know that the applicationInitialization configuration in web.config can specify warm-up paths.
10. Cloning considerations: Slot cloning copies most settings but not SSL certificates, custom domain bindings, or slot-specific settings.