Do you use Feature Flags for safer deployments?

Loading last updated info...

Deploying new features is risky - bugs can affect all users instantly. Feature flags let you deploy code to production but control who sees new features. You can gradually roll out to 1%, then 10%, then 100% of users, and instantly disable a feature if something goes wrong - no redeployment needed.

Feature flags enable trunk-based development, where all developers commit to main and features are hidden behind flags until ready.

Why feature flags matter

Safer deployments - Deploy code without exposing unfinished features
Instant rollback - Disable problematic features in seconds, not minutes
Gradual rollouts - Test with 1% of users before full release
A/B testing - Show different experiences to different user groups
Kill switches - Disable expensive features during incidents

Setting up Feature Flags with Microsoft.FeatureManagement

// Program.cs
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddFeatureManagement();

var app = builder.Build();

// appsettings.json
{
  "FeatureManagement": {
    "NewDashboard": true,
    "BetaFeatures": false,
    "ExperimentalSearch": {
      "EnabledFor": [
        {
          "Name": "Percentage",
          "Parameters": {
            "Value": 10
          }
        }
      ]
    }
  }
}

✅ Figure: Good example - Configure feature flags in appsettings.json

Using feature flags in code

// Bad - code is always executed, no way to disable
public async Task<IActionResult> GetDashboard()
{
    var data = await _newDashboardService.GetData(); // New untested code
    return Ok(data);
}

❌ Figure: Bad example - No way to disable new code if issues arise

// Good - feature can be toggled without redeployment
public async Task<IActionResult> GetDashboard(IFeatureManager featureManager)
{
    if (await featureManager.IsEnabledAsync("NewDashboard"))
    {
        var data = await _newDashboardService.GetData();
        return Ok(data);
    }

    // Fallback to old dashboard
    var legacyData = await _legacyDashboardService.GetData();
    return Ok(legacyData);
}

✅ Figure: Good example - Feature can be disabled instantly if problems occur

Feature flags in Razor/Blazor

<feature name="NewDashboard">
    <NewDashboardComponent />
</feature>
<feature name="NewDashboard" negate="true">
    <LegacyDashboardComponent />
</feature>

✅ Figure: Good example - Use feature tag helper in views

Percentage rollouts

Roll out to a percentage of users to catch issues before they affect everyone:

{
  "FeatureManagement": {
    "NewCheckout": {
      "EnabledFor": [
        {
          "Name": "Percentage",
          "Parameters": {
            "Value": 5
          }
        }
      ]
    }
  }
}

✅ Figure: Good example - Roll out to 5% of users first, increase gradually

User targeting

Enable features for specific users or groups:

{
  "FeatureManagement": {
    "BetaFeatures": {
      "EnabledFor": [
        {
          "Name": "Targeting",
          "Parameters": {
            "Audience": {
              "Users": ["[email protected]", "[email protected]"],
              "Groups": ["BetaTesters", "InternalUsers"],
              "DefaultRolloutPercentage": 0
            }
          }
        }
      ]
    }
  }
}

✅ Figure: Good example - Enable beta features only for specific users or groups

Feature flags as kill switches

During incidents, disable expensive or problematic features instantly:

app.MapGet("/api/recommendations", async (
    IFeatureManager featureManager,
    IRecommendationService recommendations) =>
{
    // Kill switch - disable expensive ML recommendations during high load
    if (!await featureManager.IsEnabledAsync("MLRecommendations"))
    {
        return Results.Ok(new { items = Array.Empty<object>(), source = "disabled" });
    }

    var items = await recommendations.GetPersonalizedAsync();
    return Results.Ok(new { items, source = "ml" });
});

✅ Figure: Good example - Disable expensive features during incidents without redeployment

When to use feature flags vs configuration

Use Feature Flags	Use Configuration
New features being developed	Stable settings (connection strings, URLs)
Gradual rollouts needed	Per-environment differences
Quick enable/disable required	Rarely changed values
A/B testing	Infrastructure settings

Best practices

Clean up old flags - Remove flags once features are fully rolled out
Name flags clearly - Use descriptive names like NewCheckoutFlow not Flag1
Default to off - New features should be disabled by default
Log flag evaluations - Track which users see which features
Test both paths - Ensure code works with flag on AND off

Do you use Feature Flags for safer deployments?

Why feature flags matter

Setting up Feature Flags with Microsoft.FeatureManagement

Using feature flags in code

Feature flags in Razor/Blazor

Percentage rollouts

User targeting

Feature flags as kill switches

When to use feature flags vs configuration

Best practices

Categories

Authors

Need help?

Do you use Feature Flags for safer deployments?

Why feature flags matter

Setting up Feature Flags with Microsoft.FeatureManagement

Using feature flags in code

Feature flags in Razor/Blazor

Percentage rollouts

User targeting

Feature flags as kill switches

When to use feature flags vs configuration

Best practices

Categories

Authors

Need help?