LEARN. PRACTICE. GROW.Concept and mechanism
App Service slots allow preparing an application and swapping contents and some configuration with production. However, not everything follows code. Managed identities remain with the slot; app settings and connection strings can be configured to stay slot-specific. Before change, confirm runtime identity, permissions, and effective destination configuration. An application accessing Key Vault in staging can fail in production if the destination identity lacks required access. Warm-up also needs interpretation: in the described default behavior, any HTTP response can count as warming up. This does not prove a business request completes correctly or dependencies are available.
Guided application
Define representative validation, error limits, and signals for stopping progressive exposure. If a canary exceeds an agreed limit, earlier build success does not authorize expansion. A feature flag can disable a function but does not undo files already sent to a partner. Recovery planning needs reconciliation and handling of external effects. The same applies to schemas: switching to the previous binary does not restore a removed column on which it depends. Plan compatibility across versions and data phases, including recovery or safe forward progress. In committee reporting, distinguish code rollback, data recovery, and business-operation completion. Decisions should use service evidence rather than only green deployment status.
Disabling the flag stops new sends, but three duplicate files already reached the partner. Recovery includes reconciliation.
Common pitfalls
Identity following code; HTTP as functional success; flag as undo; rollback without compatible schema.
Related topics: IaC, reliability, and total elapsed time · Identity, secrets, and pipeline dependencies
Plan recovery for produced effects as well as the binary.
Reference: App Service deployment slots · AZ-400 objectives 2026-07-27