Feature Flags — Controlled Rollout of New Features

A new feature is done, but the product owner wants a rollout to only 10% of users. Without feature flags that means a branch, merge hell, and two deployment pipelines. With feature flags it is one if in the code and a config change.

What Are Feature Flags¶

A condition in the code that activates or deactivates a feature. The toggle is managed externally — a config file, database, or dedicated service. Code goes to production, but the feature is “off” until you turn it on.

if (featureFlags.isEnabled("new-dashboard", currentUser)) {
    return renderNewDashboard();
} else {
    return renderOldDashboard();
}

Use Cases¶

• Canary release: Enable for 5% of users, monitor metrics
• A/B testing: Variant A vs. B, measure conversion
• Kill switch: Immediate shutdown of a problematic feature
• Trunk-based development: Everyone works on main, WIP hidden behind a flag

Managing Technical Debt¶

Feature flags are technical debt. When a feature is stably enabled for everyone, remove the flag and the old code. Otherwise you end up with hundreds of dead conditions. Rule: a flag older than 30 days = a ticket to remove it.

Feature Flags Change Deployment Culture¶

Deploy ≠ release. Code goes to production continuously, features are activated in a controlled way. Less stress, more control, faster iteration.