DevOps Feature Flags and Release Management
Feature flags (also called feature toggles or feature switches) are a technique that separates code deployment from feature release. Code ships to production in a disabled state. A feature flag controls whether specific users, segments, or environments see that feature — at runtime, without a new deployment.
This decoupling is one of the most powerful techniques in modern release management. It enables continuous delivery without the fear of exposing unfinished work.
What Are Feature Flags?
A feature flag is a conditional statement in code that wraps a new feature. The condition checks a configuration value — which can be changed without touching the code or deploying anything new.
# Without feature flags — risky big-bang release
def checkout():
process_payment_v2() # New payment flow, released to everyone at once
# With feature flags — controlled release
def checkout():
if feature_flags.is_enabled("new-checkout-v2", user=current_user):
process_payment_v2() # Show only to enabled users/percentage
else:
process_payment_v1() # Everyone else sees stable versionTypes of Feature Flags
| Type | Purpose | Lifespan |
|---|---|---|
| Release Toggle | Hide incomplete features in production | Short — removed after full rollout |
| Experiment Toggle | A/B testing and multivariate experiments | Short to medium |
| Ops Toggle | Kill switch for problematic features in production | Long-lived |
| Permission Toggle | Enable features for specific user groups or plans | Long-lived |
| Canary Toggle | Gradual percentage-based rollout | Short — removed after 100% rollout |
Benefits of Feature Flags
- Trunk-based development: All developers commit to the main branch. Incomplete features hide behind flags — no long-lived feature branches.
- Dark launches: Deploy features to production but disable them for users. Test against real production infrastructure without user impact.
- Instant kill switch: If a deployed feature causes issues, disable the flag instantly — no rollback deployment needed.
- A/B testing: Show feature version A to 50% of users and version B to the other 50%. Measure which performs better with real data.
- Canary releases: Enable for 1% of users, then 5%, 20%, 50%, 100% — monitoring at each stage.
- Beta access: Specific user groups or enterprise customers get early access to new features.
Feature Flag Targeting Rules
Modern flag systems support rich targeting conditions:
- Specific user IDs or email addresses
- User attributes: plan type (free/pro/enterprise), country, account age
- Percentage rollout: enabled for 10% of all users, based on a hash of user ID for consistency
- Environment: enabled in staging, disabled in production
- Date/time: enabled automatically after a certain date
- Beta group membership
LaunchDarkly – Enterprise Feature Management
LaunchDarkly is the leading feature management platform. It provides SDKs for every language, a management dashboard, and millisecond flag evaluation without slowing down applications.
# Python SDK example
import ldclient
from ldclient.config import Config
ldclient.set_config(Config("your-sdk-key"))
client = ldclient.get()
# Check if "new-checkout" is enabled for this user
context = ldclient.Context.builder("user-441") \
.set("plan", "enterprise") \
.set("country", "US") \
.build()
show_new_checkout = client.variation("new-checkout-v2", context, False)
if show_new_checkout:
render_new_checkout()
else:
render_classic_checkout()OpenFeature – The Open Standard
OpenFeature is a CNCF standard for feature flagging that prevents vendor lock-in. Code uses the OpenFeature SDK, which connects to any backend — LaunchDarkly, Unleash, Flagsmith, or a custom system.
# OpenFeature Java SDK example
OpenFeatureAPI api = OpenFeatureAPI.getInstance();
api.setProvider(new LaunchDarklyProvider(sdkKey));
Client client = api.getClient();
MutableContext context = new MutableContext();
context.setTargetingKey("user-441");
context.add("plan", "enterprise");
boolean showNewCheckout = client.getBooleanValue("new-checkout-v2", false, context);
if (showNewCheckout) {
renderNewCheckout();
}Self-Hosted Feature Flag Tools
| Tool | Type | Key Features |
|---|---|---|
| Unleash | Open-source, self-hosted | Full enterprise features, SDKs for all languages |
| Flagsmith | Open-source, self-hosted or cloud | Feature flags + remote config |
| Growthbook | Open-source | Feature flags + A/B testing with statistical analysis |
| ConfigCat | SaaS | Simple flags with generous free tier |
Release Strategies Using Feature Flags
Canary Release with a Feature Flag
Flag: "new-payment-engine"
Targeting rules:
- Week 1: Enable for internal users only (QA team, employees)
- Week 2: Enable for 5% of all users
- Week 3: Enable for 25% of all users
- Week 4: Enable for 100% — remove flag from codeAt each stage, monitor: error rates, latency, conversion rates, and user feedback. Any problem triggers an instant flag disable — no deployment required.
Dark Launch
Enable the new feature in production but prevent users from seeing the result. Run both old and new code paths simultaneously, log the outputs, and compare results. The new path exercises real production databases and services — catching integration issues before users ever see the feature.
Feature Flag Best Practices
- Clean up flags aggressively: Dead flags in code create confusion and bugs. Once a flag reaches 100% rollout, remove it from the codebase within two weeks.
- Name flags clearly:
enable-new-checkout-flow-2025is better thanflag-123. - Document every flag: Who owns it, what it controls, when it expires, and the rollout plan.
- Test both flag states in CI: Write tests that run with the flag both enabled and disabled.
- Limit flag nesting: Flags inside flags create untestable combinations. Keep logic flat.
- Use flags for operational emergencies: Configure kill switches for any feature that could impact billing, security, or data integrity.
Release Management Process
Feature flags are one tool in a broader release management process. A complete release process:
- Development complete: Feature passes code review, tests, and security scan.
- Deploy to production behind flag: Flag is off for all users.
- Smoke test in production: Enable flag for the internal team only, verify everything works.
- Canary rollout: Enable for 1% → 5% → 25% → 50% with monitoring gates at each step.
- Full release: Enable for 100% of users.
- Cleanup: Remove the flag from the codebase and the flag management system.
Summary
- Feature flags separate code deployment from feature release — deploy anytime, release on demand.
- Types include release toggles, experiment toggles, ops toggles, and permission toggles.
- Canary releases use flags to gradually roll out features while monitoring for problems.
- Dark launches run new code in production silently, testing against real infrastructure before user exposure.
- LaunchDarkly, Unleash, and Flagsmith provide full-featured flag management platforms.
- Old flags must be cleaned up promptly — accumulated dead flags become a maintenance and quality risk.
