3.1.4.3. Feature Flags: Azure App Configuration and Ring Deployments

3.1.4.3. Feature Flags: Azure App Configuration and Ring Deployments

Infrastructure-level deployment strategies control which version runs; feature flags control which features are visible within that version.

Feature flags (feature toggles) decouple deployment from release — new code ships to production but is hidden behind a flag until intentionally enabled. Azure App Configuration provides centralized flag management with targeting filters: combine group filters (enterprise tier) with percentage filters (10%) to roll out to specific segments. The flag lifecycle is critical: flags must have expiration dates and cleanup policies, because accumulated flags create exponential code path complexity. A toggle acting as a circuit breaker provides faster remediation than pipeline rollback — disabling a flag is instant (seconds) versus redeploying the previous version (minutes). Ring-based deployment leverages flags: same binary deploys everywhere, but ring 0 (internal) gets 100% while ring 2 (general) gets 0%, controlled entirely through flag configuration rather than separate deployments.

Content for A/B Testing in Deployment Pipelines - see flashcards and questions for this subsection.

Feature flag architecture involves three layers: the flag store (Azure App Configuration), the evaluation SDK (client libraries that check flag state), and the management interface (portal or CLI for toggling flags).

Azure App Configuration feature management supports boolean flags (on/off), conditional flags (targeting filters), and custom filters (evaluating arbitrary logic). Targeting filters combine user attributes: groups: [beta-testers], users: [alice@company.com], default_percentage: 10%. Evaluation follows a priority order: individual users → group membership → percentage rollout.

The operational lifecycle of a feature flag follows five stages: Created (flag defined, defaulting to off) → Controlled rollout (progressive percentage increase) → Fully enabled (100% of users) → Cleanup (remove conditional code, delete flag) → Archived. Flags that skip the cleanup stage become permanent technical debt — each flag doubles the code paths that need testing, and 150 accumulated flags create an unmaintainable codebase.

Configuration refresh in application code uses polling intervals: the SDK checks App Configuration every 30 seconds (configurable) for changes. Sentinel keys enable instant propagation — change a sentinel value to trigger all connected applications to refresh their configuration simultaneously. This is faster than waiting for individual polling intervals to expire.

Kill switches are permanent feature flags designed for emergency circuit-breaking: disable a problematic feature in production without deployment. Unlike temporary feature flags, kill switches should never be cleaned up — they're a permanent safety mechanism.

Feature flag testing requires exercising both code paths — flag on AND flag off — in your test suite. Without this discipline, the "off" path accumulates untested code that breaks when the flag is eventually removed. Integration tests should parameterize flag states: run the same test suite twice with different flag configurations. This doubles test time but catches the "removing the flag breaks the feature" bug that commonly occurs during cleanup.

Azure App Configuration supports configuration snapshots — point-in-time captures of all feature flag and configuration values. Before a deployment, create a snapshot of the current configuration. If the deployment causes issues, restore the snapshot to revert all configuration changes simultaneously. This provides a configuration-level rollback independent of code deployment rollback.

Custom feature flag providers beyond App Configuration include LaunchDarkly, Split.io, and Flagsmith. The Microsoft.FeatureManagement library abstracts the provider, allowing teams to swap implementations without changing application code. Server-side evaluation ensures consistent flag state across requests.

Flag evaluation must be consistent within a single request. If a flag value changes mid-request, the user might see a partially enabled feature — new UI components pointing to old API endpoints. Cache flag state at request initialization and use that snapshot throughout the request lifecycle.

Feature management telemetry should track flag evaluation results. Logging which flags are evaluated, for which users, and which branch was taken enables debugging and A/B testing analysis without separate analytics infrastructure.