App Service Deployment Slots and Swap Strategies

Explore Deployment Slot Configuration and Management

Deployment Slot Basics

Azure App Service deployment slots are individual, live instances of your web application that run within the same App Service plan. These slots act as staging environments that allow developers to deploy and test new versions of an application before making them public. Because each slot has its own unique hostname and URL, you can run tests safely without affecting your active users. This architecture ensures a smooth deployment process and helps you achieve a deployment with zero downtime.

Creating and Managing Slots

Developers can create and manage deployment slots using several administrative tools. You can use the Azure Portal for a visual interface, or use command-line options like the Azure CLI and Azure PowerShell to automate the process. When creating a new slot, you can choose to clone the configuration from an existing slot or build one with brand new settings. Each slot appears as a distinct app resource in your resource group, allowing you to manage and secure them independently.

Production and Staging Environments

Deployment slots make it easy to separate your development lifecycle into production and staging environments. Best practices recommend enabling continuous deployment on your staging slot so new code changes deploy automatically for immediate testing. In contrast, you should disable continuous deployment on your production slot to prevent unverified updates from accidentally going live. When your staging code is fully verified, you perform a swap to exchange the contents of the staging and production slots.

Categorize and Manage Configuration Persistence

Sticky and Swappable Settings

When you configure an app, you must understand which settings travel with your code during a swap and which stay behind. Slot-specific settings, also known as sticky settings, are configurations tied directly to a specific slot environment that never change during a swap. These include critical environment configurations like custom domains, SSL certificates, publishing endpoints, and IP restrictions. In contrast, non-slot-specific settings represent general application settings that swap automatically to ensure the new application version runs with its matching configuration.

Managing Configuration During Swaps

To make a database connection string or environment variable sticky, you must mark it as a deployment slot setting in the Azure portal. You must configure these settings across all slots involved in the swap to prevent application errors caused by missing configurations. During a swap, the source slot temporarily applies the target slot's settings and restarts its instances to verify stability. If any instance fails to start up properly during this phase, Azure automatically rolls back the entire swap to protect your active environment.

Execute Advanced Swap and Traffic Routing Strategies

Swap with Preview and Auto Swap

A standard slot swap instantly exchanges the content and configuration between your source and target slots. For greater control, you can use swap with preview, which pauses the swap process after applying production settings but before routing actual user traffic. This pause allows developers to validate the app under true production configurations, giving them the option to complete the swap or reset it to the original state. Alternatively, you can configure auto swap to automatically trigger the exchange as soon as new code is pushed and the instances are successfully warmed up.

Traffic Routing and Testing in Production

Traffic routing allows you to perform testing in production by directing a specific percentage of user traffic to a non-production slot. This technique is highly effective for monitoring how a new application version performs with a real audience before a full release. You can use the Azure portal to manually adjust the routing percentage to support different testing strategies:

• Canary Testing: This strategy deploys a new version to a small, controlled group of users to monitor for bugs and system stability.
• A/B Analysis: This strategy splits traffic between two different versions of an application to compare user engagement and performance results.