When working with Azure App Service deployment slots, there are two types of settings that you need to understand: Swapped Settings and Slot-Specific Settings.
These settings define how configuration values are handled during slot swaps, and they affect your deployment strategies.
Here’s a breakdown of the two.
Swapped Settings (Sticky Settings)
Definition
Swapped settings, also referred to as "sticky settings," are settings that remain with the slot when you perform a swap between slots (e.g., swapping a staging slot with the production slot).
Purpose
These settings allow you to have configurations that should not change when a swap occurs.
This is useful for things like database connection strings, third-party API keys, or any environment-specific configuration that must remain constant across slot swaps.
How it Works
When you deploy to a slot (e.g., staging), some settings may be marked as swapped.
These settings will stay with the slot when you swap it with another slot.
For example, if you're swapping a staging slot with a production slot, any swapped settings from the staging slot will be retained in the production environment after the swap.
Examples of Swapped Settings
Database connection strings (you typically don't want your production database to switch to a test database after swapping slots).
API keys or authentication tokens that are environment-specific.
Configuring Swapped Settings
In the Azure Portal, you can configure a setting to be "sticky" by selecting Slot Setting when you add or update an application setting or connection string.
When using Azure CLI or ARM templates, the slotSetting property is set to true for a particular setting to make it sticky.
Behavior
When you swap slots, the settings marked as swapped will not move with the slot they are in.
For example:
If the staging slot has a database connection string for a test database and you mark this as swapped, when you swap staging with production, the production environment will keep the test database connection string from the staging slot.
Slot-Specific Settings (Non-Swapped Settings)
Definition
Slot-specific settings are environment-specific settings that change when a slot is swapped.
These settings are unique to each deployment slot.
Purpose
These settings are used for configurations that should change when you swap the slots, such as environment-specific settings for staging, development, or testing.
How it Works
Settings that are not marked as swapped will move with the slot during a swap.
When you deploy an app to a slot (e.g., staging), the settings in that slot are specific to it.
If you swap staging with production, the configuration in staging will overwrite the configuration in production (and vice versa) for settings that are not sticky.
Examples of Slot-Specific Settings
Application settings for the app's behavior in different environments (e.g., logging level or feature flags).
Debugging or diagnostic settings for different environments (you might have different logging levels in staging vs. production).
API endpoints for different environments (staging may connect to a different service endpoint than production).
Configuring Slot-Specific Settings
When adding or updating application settings or connection strings in the Azure Portal, do not mark the setting as sticky, and it will remain slot-specific.
In Azure CLI or ARM templates, omit the slotSetting property (or set it to false) for the setting to make it slot-specific.
Behavior
When a slot is swapped, the settings that are not marked as swapped will move with the slot.
For example:
If the staging slot has a setting for FEATURE_FLAG=true and production has FEATURE_FLAG=false, and you swap staging with production, the FEATURE_FLAG setting from staging will be applied to production after the swap, and vice versa.
Key Differences Between Swapped Settings and Slot-Specific Settings
| Feature | Swapped Settings | Slot-Specific Settings |
|---|---|---|
| Behavior on Slot Swap | Stay with the slot (do not swap) | Move with the slot (swapped settings overwrite) |
| Usage | Use for environment-specific settings that must not change (e.g., DB connection strings, secret keys). | Use for settings that should differ between slots (e.g., logging level, feature flags). |
| Configuration | Mark the setting as sticky using Azure Portal, CLI, or ARM templates. | Leave the setting unset or do not mark as sticky. |
| Examples | Database connection strings, API keys, secrets, and anything that must remain stable across slots. | Debug settings, feature toggles, API endpoints, and other environment-specific configurations. |
| Effect on Production | Will remain the same after a swap (e.g., production keeps the staging DB connection). | Will change after a swap (e.g., production might switch to staging's logging settings). |
Practical Considerations
Testing in Staging: When deploying to a staging slot, you may want to use slot-specific settings for things like debug logging or feature flags that are unique to the staging environment. When you swap to production, these settings will be replaced by those from production.
Database and Secrets: Mark sensitive settings such as database connection strings or API keys as swapped settings to ensure they don't inadvertently change during slot swaps.
Ease of Deployment: Using slot-specific settings can make it easy to configure each environment differently without needing to update the production slot directly.
Summary
Understanding the distinction between swapped and slot-specific settings is crucial for managing your app's configuration across different deployment slots.
Swapped settings are ideal for things that must remain constant across environments (like database connections), while slot-specific settings are great for environment-specific configurations that need to change with each slot swap.
By leveraging both types of settings effectively, you can streamline your deployment and testing processes while minimizing the risk of disruptions.
Leave a Reply