Configuring Deployment Slots for Staging and Production Swapping

1. What Are Deployment Slots?

At its core, a deployment slot is a live, running instance of your web app with its own unique hostname. Your default App Service instance is called the "production" slot. You can create additional slots, such as "staging," which run on the same App Service Plan, meaning they share the same compute resources and don't typically incur extra costs.

The primary benefits of using deployment slots are:

• Validation: You can deploy new changes to a non-production slot (e.g., staging) and test them thoroughly in a production-like environment.
• Zero-Downtime Swaps: When you're ready, Azure "warms up" the staging slot and then swaps it with the production slot. This is a fast operation that redirects traffic, ensuring no requests are dropped.
• Easy Rollbacks: If you discover an issue after a swap, the old production code is now in the staging slot. Rolling back is as simple as performing another swap.

To get started, let's read the official introduction to this feature.

2. Creating and Deploying to a Staging Slot

Let's put this into practice. You'll now create a staging slot for the web app you deployed in the previous lessons. We will continue using the Azure CLI to automate these tasks.

Step 1: Create a Staging Slot
Open your terminal and run the following command. Remember to replace the placeholder values with your unique app name and resource group.

az webapp deployment slot create --name <your-unique-app-name> --resource-group <your-resource-group-name> --slot staging

This command creates a new slot named staging. It will have its own URL, typically http://<your-unique-app-name>-staging.azurewebsites.net.

Step 2: Deploy Updated Code to the Staging Slot
Now, let's make a change to our application and deploy it specifically to the new staging slot.

1. In your local MyFirstAzureWebApp project, open Pages/Index.cshtml.

2. Modify the <h1> tag to reflect that this is a new version. You can use the existing configuration value or change the text entirely. Let's update it to:

   <h1 class="display-4">Welcome to Version 2.0</h1>
   

3. Now, deploy the application, but this time, target the staging slot using the --slot parameter.

   az webapp up --name <your-unique-app-name> --resource-group <your-resource-group-name> --slot staging
   

After the deployment completes, navigate to your staging URL (http://<your-unique-app-name>-staging.azurewebsites.net). You should see "Welcome to Version 2.0." Meanwhile, your production URL (http://<your-unique-app-name>.azurewebsites.net) will still show the original version.

To see this process in action, watch this short video from Microsoft.

3. Performing the Swap

With your new code tested and verified on the staging slot, you're ready for the main event: swapping it into production. The swap operation is what enables a zero-downtime deployment.

To perform the swap, use the following CLI command:

az webapp deployment slot swap --name <your-unique-app-name> --resource-group <your-resource-group-name> --slot staging --target-slot production

After the command completes:

• Navigate to your production URL. You will now see "Welcome to Version 2.0."
• Navigate to your staging URL. You will see the old version of the site that was previously in production.

This immediate rollback capability is one of the most powerful aspects of deployment slots. If you find an issue, you can simply run the same swap command again to revert to the previous state instantly.

4. Configuring Slot-Specific ("Sticky") Settings

This is a critical concept that builds on our last lesson. When you swap slots, the application code and most configurations are swapped. However, some settings, like a connection string to a staging database, should not move to production. These are called slot-specific or "sticky" settings.

When you mark a setting as slot-specific, it remains attached to the slot regardless of any swaps.

Let's explore what gets swapped and what can be made sticky.

Hands-On: Configuring a Sticky Setting

Let's test this. We'll create a new setting to identify the environment and make it sticky.

1. Add a sticky setting to the production slot:
   Note that we don't specify a --slot parameter here, as we are targeting the default production slot.

   az webapp config appsettings set --name <your-unique-app-name> --resource-group <your-resource-group-name> --settings "EnvironmentName=Production" --slot-settings "EnvironmentName"
   

   The --slot-settings parameter is the key: it designates EnvironmentName as sticky.

2. Add the same sticky setting to the staging slot:

   az webapp config appsettings set --name <your-unique-app-name> --resource-group <your-resource-group-name> --slot staging --settings "EnvironmentName=Staging" --slot-settings "EnvironmentName"
   

3. Update your code to display the environment name:
   In Pages/Index.cshtml, add a new line to display this setting. Your file should now look something like this:

   @page
   @inject Microsoft.Extensions.Configuration.IConfiguration Configuration
   
   <div class="text-center">
       <h1 class="display-4">Welcome to Version 2.0</h1>
       <h2>Environment: @Configuration["EnvironmentName"]</h2>
       <p>Learn about <a href="https://docs.microsoft.com/aspnet/core">building Web apps with ASP.NET Core</a>.</p>
   </div>
   

4. Deploy the update to the staging slot:

   az webapp up --name <your-unique-app-name> --resource-group <your-resource-group-name> --slot staging
   

5. Test and Swap:

   • Visit your staging URL. It should say "Welcome to Version 2.0" and "Environment: Staging".
   • Visit your production URL. It should show the old code and "Environment: Production".
   • Now, perform another swap:

     az webapp deployment slot swap --name <your-unique-app-name> --resource-group <your-resource-group-name> --slot staging
     

   • After the swap, refresh both URLs.
     • The production URL now shows "Welcome to Version 2.0" but correctly displays "Environment: Production". The code was swapped, but the sticky setting was not.
     • The staging URL now shows the old code but correctly displays "Environment: Staging".

5. Advanced Swapping: Swap with Preview and Auto Swap

For mission-critical applications, you can perform an even safer swap using a two-phase process called Swap with Preview.

1. Phase 1 (Preview): App Service applies the production slot's settings (including sticky ones) to the staging slot and warms it up, but does not redirect traffic. This lets you run final tests on the staging slot with the exact production configuration.
2. Phase 2 (Complete): If everything looks good, you complete the swap. If not, you can cancel it.

Conclusion

You've now mastered one of the most powerful features of Azure App Service for managing application lifecycles. Deployment slots are essential for professional, reliable deployments.

Here are your key takeaways from this lesson:

• Deployment slots are separate, live environments for testing updates without affecting production.
• Swapping is a near-instant, zero-downtime operation that redirects traffic between slots.
• Rollbacks are as simple as swapping back, providing a rapid recovery mechanism.
• Sticky settings are crucial for managing environment-specific configurations (like connection strings) that should not be swapped with the code.
• Advanced techniques like Swap with Preview and Auto Swap provide additional safety and automation for your deployment process.

In our next and final lesson for this module, we will explore another critical aspect of managing a production application: auto-scaling. You'll learn how to configure your App Service to automatically scale out to handle more traffic and scale in to save costs.