Feature Flags & Progressive Delivery Vocabulary: 25 Terms Explained
Learn feature flag vocabulary for modern delivery — toggles, percentage rollouts, canary releases, kill switches, flag debt, LaunchDarkly, Unleash, and more.
Modern software teams no longer deploy and pray. They deploy incrementally, gate features behind flags, and roll back instantly if something goes wrong. Feature flags — also called feature toggles or feature switches — are at the heart of this approach. If your team practises trunk-based development or progressive delivery, this vocabulary is essential for daily standups, incident reviews, and planning discussions.
Core Concepts
Feature Flag (Toggle / Switch)
A feature flag (also called a feature toggle or feature switch) is a conditional in your code that enables or disables a feature without deploying new code. Instead of making code changes to turn something on, you change configuration.
“We shipped the new onboarding flow behind a feature flag. We can enable it for specific users without a new deployment.”
Flag Lifecycle
Every feature flag has a lifecycle:
- Create — define the flag in your system and write the conditional in code
- Enable — turn it on, initially for a small group
- Rollout — gradually increase the percentage of users who see it
- Retire — once the feature is fully released, remove the flag and the conditional from the code
“This flag has been sitting in the codebase for three months. It’s time to retire it — remove the conditional and clean up the code.”
Targeting Rule
A targeting rule determines who sees a feature. Rules can target by user ID, email domain, country, account plan, or any other attribute.
“Set a targeting rule so only users on the beta plan see the new editor — we’re not ready to release it to everyone.”
Percentage Rollout
A percentage rollout enables a feature for a defined percentage of users — for example, 5%, then 20%, then 100%. It limits the blast radius if something goes wrong.
“Start with a 1% rollout. If no errors appear in the next hour, bump it to 10%.”
Deployment Strategies
Canary Release
A canary release is a deployment strategy where a new version of the application is rolled out to a small subset of users (the canary group) before everyone else. The name comes from the miners’ canary — an early warning system.
“We’re doing a canary release to 5% of production traffic. Watch the error rate and latency — if anything spikes, we roll back.”
Blue-Green Deployment
In a blue-green deployment, you maintain two identical production environments — blue (current) and green (new). You deploy to green, test it, then switch traffic from blue to green. If problems arise, you flip back to blue instantly.
“Blue-green gives us zero-downtime deployments. The switch is instant — just a DNS or load balancer change.”
Ring Deployment
A ring deployment releases changes through a series of rings — from internal employees, to beta users, to a small percentage of customers, and finally to everyone. Each ring is a checkpoint.
“Our deployment rings are: internal → 1% → 10% → 100%. We spend at least 24 hours in each ring.”
Dark Launch
A dark launch means running new code in production for real traffic without showing the results to users. You test the performance and correctness of the new code path in silence.
“We dark-launched the new recommendation engine for two weeks. It processed real requests but we discarded the output. Once we were confident, we turned on the flag.”
Risk Management
Kill Switch
A kill switch is a flag specifically designed to disable a feature instantly in an emergency. Unlike a gradual rollout, a kill switch is binary — on or off — and is operated by on-call engineers, not product managers.
“The payment integration has a kill switch. If it starts failing, flip the switch and fall back to the legacy flow immediately.”
Rollback
A rollback means reverting to a previous state. With feature flags, you can “roll back” a feature by disabling the flag — no code deployment required.
“We don’t need to roll back the deployment. Just disable the flag and users will get the old behaviour.”
Technical Debt and Hygiene
Flag Debt
Flag debt is the accumulated cost of feature flags that are never retired. Old flags clutter the code, create confusion about what is enabled, and can interact unexpectedly with new flags.
“We have 80 flags in the codebase and only 20 are still active. The rest are flag debt — let’s schedule a cleanup sprint.”
Trunk-Based Development and Feature Flags
In trunk-based development, all developers commit to a single main branch (the trunk) frequently. Feature flags enable this by allowing incomplete features to be merged and deployed without being visible to users.
“We don’t use long-lived feature branches. We merge to trunk daily and use feature flags to hide work in progress.”
Feature Flag Platforms
LaunchDarkly
LaunchDarkly is a leading commercial feature flag platform. It provides a dashboard for managing flags, targeting rules, and percentage rollouts, with SDKs for all major languages and frameworks.
“LaunchDarkly lets the product team change targeting rules without involving engineers.”
Unleash
Unleash is an open-source feature flag platform. Teams who want to self-host their flag infrastructure often choose Unleash.
“We self-host Unleash on our own infrastructure — no third-party dependency for flag evaluation.”
Flagsmith
Flagsmith is another open-source alternative to LaunchDarkly, supporting both cloud-hosted and self-hosted deployments.
Common Feature Flag Phrases
| Phrase | Meaning |
|---|---|
| ”Gate it behind a flag” | Don’t release it to all users — put a flag in front of it |
| ”Flip the flag” | Enable or disable the feature |
| ”The flag is stale” | The feature is fully released but the flag hasn’t been removed from the code |
| ”We can roll back without a deploy” | Turn off the flag to revert the behaviour |
| ”Gradual rollout” | Increasing the percentage of users who see the feature over time |
| ”The blast radius is limited” | Only a small percentage of users are affected if something goes wrong |
| ”Flag hygiene” | The practice of retiring old flags and keeping the flag inventory clean |
Understanding the Nuances of “Rollout” in a Team Context
The term “rollout” – frequently used when discussing feature flags – can be surprisingly tricky for non-native English speakers. It’s often presented as simply “making a feature available to users,” but it carries a significant amount of operational and strategic weight, especially within a development team. It’s not just about deploying code; it’s about the process of making that deployment impactful. A common misunderstanding comes from equating “rollout” with simply hitting a “deploy” button. That action is necessary, certainly, but it’s only the first step in a carefully orchestrated plan.
Consider this scenario: During a code review, a senior engineer might comment on a PR description saying, “This rollout looks good conceptually, but we need to add more detail about the target user segment for this percentage-based release – let’s clarify what constitutes ‘critical’ users before we proceed.” This isn’t criticism; it’s an observation highlighting the strategy behind the rollout. The engineer is asking for a deeper understanding of why that particular group is being targeted, and how success will be measured. Similarly, in Slack, you might see messages like, “Rolling out v2 to 10% of users this afternoon – monitoring key metrics closely.” The emphasis here isn’t just on the action; it’s about continuous observation and adaptation. A poorly defined rollout can quickly become “flag debt,” accumulating unused flags and complicating future deployments.
Furthermore, the concept of a “gradual rollout” is often misinterpreted. It doesn’t mean simply deploying to 1% initially. It means carefully controlling who sees the feature, when they see it, and how its performance is monitored at each stage. A successful rollout isn’t about blindly pushing code; it’s about iterative learning and risk mitigation. It requires a clear understanding of your metrics – conversion rates, error rates, user engagement – and the ability to quickly react if something goes wrong (hence the importance of having a “kill switch”).
Let’s illustrate this with an example using LaunchDarkly:
launchdarkly set feature-name=true segment="new_users" region="us-east-1"This command, while seemingly simple, represents a deliberate action – setting a flag to a specific segment in a particular region. The rollout isn’t just the command itself; it’s the entire process of defining that segment, monitoring its impact, and adjusting the rollout strategy based on those observations. It’s about understanding how different segments react, and ensuring the feature is delivering value to the intended users.