Feature Flags with Azure App Configuration

Feature flags (also known as feature toggles) are a software development technique that allows you to turn functionality on or off at runtime without deploying new code. Instead of using traditional if statements that are hardcoded, you wrap a feature in a conditional check against a configuration source. The flag's value (true/false) is stored externally—typically in Azure App Configuration—and can be changed on the fly. This decouples deployment from release: you can deploy code that is 'dark' (disabled) and later enable it for specific users or percentages.

The primary motivations for feature flags are: - Safe deployment: Roll out features gradually to catch issues early. - Targeted rollouts: Enable features for specific user segments (e.g., beta testers). - Instant kill switch: Disable a problematic feature immediately without rollback. - A/B testing: Run experiments with different feature states. - Environment-specific behavior: Enable debug features in dev, disable in prod.

Azure App Configuration is a managed service that stores configuration key-value pairs and feature flags. Feature flags are stored as a special type of key-value with a prefix .appconfig.featureflag/. Each flag has: - ID: A unique identifier (e.g., "BetaSearch"). - Description: Optional human-readable text. - Enabled state: Boolean true/false. - Filters: An array of filter objects that determine when the flag is enabled for a given user/context.

Filters are evaluated at runtime. The most common filters are: - Percentage filter: Enables the feature for a random percentage of users (based on a user ID hash). - Time window filter: Enables the feature during a specific date/time range. - Targeting filter: Enables the feature for specific users, groups, or rollout percentages.

Under the hood, Azure App Configuration uses a REST API. When you create or update a feature flag via the portal, CLI, or SDK, it sends a PUT request to the store. The flag's JSON representation looks like:

{
  "id": "BetaSearch",
  "description": "Enable new search algorithm",
  "enabled": false,
  "conditions": {
    "client_filters": [
      {
        "name": "Microsoft.Targeting",
        "parameters": {
          "Audience": {
            "Users": ["user1@contoso.com"],
            "Groups": ["BetaTesters"],
            "DefaultRolloutPercentage": 10
          }
        }
      }
    ]
  }
}

To consume feature flags in your application, you use the Microsoft.FeatureManagement library (for .NET) or equivalent libraries for other languages. This library provides: - IFeatureManager: Core interface to check if a feature is enabled. - IFeatureManagerSnapshot: Caches flag evaluations for the duration of a request (important for performance). - [FeatureGate] attribute: Allows declarative feature gating on controllers/actions.

How evaluation works: 1. Application calls await featureManager.IsEnabledAsync("BetaSearch"). 2. The library fetches the feature flag from Azure App Configuration (or local cache). 3. If the flag's enabled property is false, return false immediately (short-circuit). 4. If enabled is true, iterate through each filter in client_filters. 5. For each filter, call its Evaluate method with the context (user ID, etc.). 6. If any filter returns true, the feature is enabled; otherwise, it's disabled. 7. Results are cached according to the cache expiration setting (default 30 seconds).

Important: The enabled property acts as a master switch. If it's false, no filters are evaluated. If true, filters must also pass. This means you can have a flag that is globally enabled but filtered to only 10% of users.

Azure CLI:

Create a feature flag:

az appconfig feature set --name myAppConfig --feature BetaSearch --description "New search" --enabled true

Add a targeting filter:

az appconfig feature filter add --name myAppConfig --feature BetaSearch --filter-name Microsoft.Targeting --parameters '{"Audience":{"Users":["alice@contoso.com"],"DefaultRolloutPercentage":25}}'

List all feature flags:

az appconfig feature list --name myAppConfig

Enable a flag:

az appconfig feature enable --name myAppConfig --feature BetaSearch

Portal: Navigate to your App Configuration resource, select "Feature manager" under Operations. You can create/edit/delete flags and add filters via the UI.

Verification: Use the portal's "Test" button to simulate a user ID and see if the flag would be enabled. Or use the CLI with az appconfig feature show to view the full JSON.

In a .NET Core application, you register the feature management services in Startup.cs:

public void ConfigureServices(IServiceCollection services)
{
    services.AddAzureAppConfiguration()
        .Connect(Environment.GetEnvironmentVariable("ConnectionString"))
        .UseFeatureFlags();
    
    services.AddFeatureManagement();
}

Then use middleware to refresh configuration periodically:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseAzureAppConfiguration();
    // ...
}

In a controller:

[ApiController]
[Route("api/[controller]")]
public class SearchController : ControllerBase
{
    private readonly IFeatureManager _featureManager;

    public SearchController(IFeatureManager featureManager)
    {
        _featureManager = featureManager;
    }

    [HttpGet]
    public async Task<IActionResult> Get()
    {
        if (await _featureManager.IsEnabledAsync("BetaSearch"))
        {
            return Ok("New search results");
        }
        return Ok("Old search results");
    }
}

Or use the [FeatureGate] attribute:

[FeatureGate("BetaSearch")]
[HttpGet("new")]
public IActionResult NewSearch()
{
    return Ok("New search endpoint");
}

If the feature is disabled, the framework returns a 404 (NotFound) result automatically.

A large e-commerce company wants to roll out a new recommendation engine to 10% of users initially. They create a feature flag NewRecommendations with a percentage filter set to 10. The user ID is the customer's email hash. The flag is stored in Azure App Configuration. The application checks the flag on every page load. After one week, they increase to 50%, then to 100% after monitoring conversion rates. If a bug is found, they disable the flag immediately. The team uses the Azure CLI for automation and integrates flag changes into their CI/CD pipeline via Azure DevOps. Performance is critical: they set cache expiration to 15 seconds to balance freshness and cost. They use IFeatureManagerSnapshot to avoid repeated calls within the same request.

A SaaS provider wants to give beta access to specific enterprise customers. They create a feature flag BetaDashboard with a targeting filter that includes a list of user object IDs (from Azure AD) and a group "BetaTesters". The flag is enabled globally, but the filter restricts it to those users. They also set a default rollout percentage of 0 to ensure no one else sees it. The application uses the [FeatureGate] attribute on the beta dashboard controller. When a new customer signs up for beta, an admin adds their user ID to the targeting filter via the portal. The change takes effect within the cache interval. The team monitors usage via Application Insights and can disable the feature for a specific user by removing them from the list.