Feature Flags | Harness Glossary | Harness Glossary

Tired of white‑knuckle releases and late‑night deploys? Feature flags let you ship continuously, test safely in production, and control exactly who sees what, without redeploying or risking an all‑or‑nothing launch. 

Harness Feature Management & Experimentation plugs into your existing CI/CD workflows to bring enterprise-grade feature flags, built‑in experimentation, and real‑time impact tracking together in one place.

What Are Feature Flags?

Feature flags (also known as feature toggles, release toggles, feature flippers, and remote configurations) are a software development tool that allow you to enable or disable a feature without modifying the source code or performing a new deployment. 

Feature flags are typically used in conditional statements (e.g. if-then-else) to determine which code path will be executed. Their power lies in the ability to determine at runtime which functionality is executed and to make these decisions at the user or request level, not just globally. With feature flags, you can deploy new features in a dormant “turned off” state, so they are not initially available to users or executed by back-end processes.  When ready, you can selectively turn these features on for specific subsets of users and environments. Here is a simplified pseudocode example:

if (featureFlag("new-checkout-flow", user)):
    showNewCheckout()
else:
    showLegacyCheckout()

Key characteristics of feature flags include:

• Runtime evaluation: Flags are evaluated during execution, not at build time, and flag changes can be propagated dynamically without restarting servers or running a CI/CD pipeline.
• Granular targeting: Flags can control whether code executes at the individual user, segment, or request level (e.g. "all users in Europe" or "10% of new signups").
• Decoupled deploy and release: New code can ship to production in an "off" state and be selectively turned on when ready.

These characteristics differentiate feature flags from static configuration files or environment variables, which typically require a restart or redeployment to take effect.

Decoupling Deploy From Release

Historically, taking a release live was accomplished by deploying code to a production environment. From that moment onward, the update was live for all users. The high risk of disrupting production by introducing unstable code compelled teams to bundle multiple features into large releases that might happen weekly, monthly, or even once a quarter. Testing all of these changes together in an environment that accurately represented production was challenging.

Even a heavy investment in complex test environments did not remove the anxiety over the actual production release, so deployments would be performed late at night or on weekends, when few users would be impacted. If a problem did become evident in production, typically, the entire release would be rolled back and all features, whether broken or not, would be forced back into a “develop, integration test, and wait for next release” loop. 

This process was painful and led to development and delivery velocity slowing with each new release. Cloud solutions teams were especially impelled to improve on this antiquated way of releasing code. They spearheaded feature flags as a way to ship new functionality to production environments and ultimately to their end users with less dependency on cross-team coordination or bundling features into large-scale releases.

The advantages of separating deployment from release:

• Deployment becomes low-risk. Code moves into production in an "off" state. Since it doesn't execute, nothing changes for users.
• Release becomes independent. Each feature can be turned on individually, at any time, for any audience, without a new build or deploy cycle.
• Teams are decoupled from each other. No more waiting for every team's changes to be assembled into a single "big bang" release.

This shift has a direct, positive impact on all four DORA metrics (deployment frequency, lead time for changes, change failure rate, and mean time to recovery/MTTR), the industry-standard benchmarks of high-performing engineering teams.

How Feature Flags Change Software Development

Feature flags equip teams to move much faster and achieve far better outcomes. Consider how feature flags have become a game-changer for software development:

Trunk-Based Development

Feature flags eliminate the need for long-lived feature branches. When work in progress can be merged to the main branch behind a flag in the "off" state, teams can practice trunk-based development — committing to a single shared branch and merging frequently. 

Benefits include:

• Fewer merge conflicts and easier debugging
• Continuous integration of code changes across the team
• Short-lived branches (if any), used for code review via pull requests

The key insight is that the separation of work-in-progress from production code can be handled by the abstraction of flags, not by separate branches in the code repository.

Progressive Delivery

Feature flags enable progressive delivery, the practice of gradually expanding the audience for a new feature through controlled stages:

• Internal dogfooding: Release first to the development team.
• Stakeholder review: Expand to QA, product managers, or design partners.
• Beta / early access: Open to early adopters or opt-in beta testers.
• Percentage rollout: Incrementally increase from 5% → 25% → 50% → 100% of users.
• Full general availability.

Progressive delivery promotes tight feedback loops and lessens risk because at each stage you can monitor metrics and user feedback before expanding further — or instantly roll back if issues arise.

Synchronized releases

You can synchronize releases with marketing campaigns while you sleep. New functionality deployed behind a feature flag today can be scheduled for release next week, without requiring a redeployment or any other actions by the engineering team. Instead of waiting up to deploy and verify a release moments before a marketing launch, you deploy and test in production during regular work hours and use a flag to activate the feature during off hours.

Code stability

When you deploy features in the dormant inactive state, and then activate them by flipping a feature flag, you remove much of the stress of releasing. This is because the deployment becomes a non-event. Any feature that causes an incident is easily detected and switched off, without the time and coordination required for a multi-step rollback or hotfix. Your team’s mean time to remediate (MTTR), a key DORA metric, will be a small fraction of what it would otherwise be. And by improving the psychological safety of releases, your team will be inclined to do them more often.

Observability

Observe the performance and behavior of each feature before all users see it. Modern feature flag platforms go beyond simple on/off control. They compute metrics at the individual flag level — comparing the behavior and performance of metrics for each variant of the flag. This provides significantly deeper insight than global application metrics or basic blue/green and canary deployments alone.

Look at Four Shades of Progressive Delivery if you want to compare the value of blue/green, canary releases, feature flag rollouts alone, and feature flags with metrics computed at the feature flag level.

Types of Feature Flags

Understanding the different types of feature flags helps teams choose the right approach and manage flag lifecycles effectively:

• Release flags: The most common type, used to hide incomplete or untested features behind a toggle so code can be merged to trunk and deployed safely. These are short-lived and should be removed once the feature is fully rolled out.
• Experiment flags: Used for A/B testing and multi-variant experiments. These control which variant of a feature a user sees and are tied to a hypothesis and success metric. They are removed after the experiment concludes and a winner is chosen.
• Operational flags: Used to control system behavior in production (e.g. toggling a circuit breaker, rate-limiting a resource, or switching between a primary and fallback service). These may be long-lived or permanent.
• Permission flags: Used to gate access to features based on user attributes such as subscription tier, role, geography, or account type. Often permanent, these flags power entitlement and feature-gating strategies.

A useful mental model is to categorize flags along two dimensions: longevity (short-lived vs. long-lived) and dynamism (how frequently the flag value changes during its lifetime). Release flags are short-lived and change rarely (typically toggled once). Experiment and operational flags may be more dynamic. Permission flags are long-lived but relatively static per user.

Who Uses Feature Flags?

Feature flags were adopted first by development teams in leading tech companies as part of continuous integration and deployment (CI/CD) implementing tight release cycles. They have grown in popularity, even with smaller teams that benefit from trunk-based development, safe deployments, testing in production, and experimentation.

Feature flag–centered methodologies have extended beyond the developers who evaluate flags in code. Modern feature management platforms have made flags accessible to non-engineering teams:

• QA, designers, product managers, and other stakeholders can perform testing in production to validate changes without needing a developer or a separate environment.
• Sales, Customer Success, and Support can add and remove entitlements for specific customers without a custom deployment.
• Product Management can manage beta program participation right in the production environment.
• Product and Marketing can iterate A/B tests without code changes, a practice that’s often known as dynamic configuration.

Creating, operating, and tracking feature flags with a feature management platform makes feature flags a standard and easily understood part of getting things done throughout the software delivery lifecycle.

Feature Flag Use Cases and Benefits

Feature flags make it easier to:

• Reduce the surface area of bugs by using progressive delivery instead of big-bang releases to all users.
• Facilitate QA and beta testing by deploying to production, but setting feature flag targeting just to specific QA and beta users. 
• Streamline launch coordination and the sequencing of complex product launches.
• Avoid code freezes.
• Perform safer technology migrations with the feature parity testing pattern.
• Split up a monolith gradually (not as a rip and replace or big bang) using the strangler fig pattern.
• Target specific accounts or other granular segments with different experiences from the same codebase.
• Change features dynamically in production (text copy, pricing, and other aspects of user experience) without burning software development time to code, test, deploy, and release each time.
• Manage multi-channel touch points, coordinating release and exposure of new features across web, mobile, and partner platforms by simply toggling flags.

How Are Feature Flags Implemented?

Feature flag implementation typically evolves through three stages as teams mature:

Stage 1: Configuration files and environment variables 

Many teams start by listing features as "on" or "off" in a config file, environment variable, or command-line argument. This works for hiding work in progress in test environments, but doesn't support runtime changes, per-user targeting, or instant rollback; so it doesn't truly decouple deploy from release.

Stage 2: Database-backed flags 

More advanced homegrown solutions store flags in a database, often as columns in a user table or key-value pairs in a user object. This can support user-level targeting, but it scales poorly. Each new flag may require schema changes, and it rarely supports powerful targeting rules (e.g. "all users on the west coast") or instant kill-switch behavior.

These shortcomings can be overcome by investing in building more advanced functionality, but it’s challenging to prioritize building and operating a sophisticated feature flag as a service solution for your developers over adding new features to your roadmap for the user base, so it seldom happens.

Stage 3: Feature management platforms 

As organizations discover the value of feature flags, most adopt a dedicated feature management platform — either open-source or commercial. These platforms offer:

• SDKs for all major languages and frameworks (client-side, server-side, and mobile)
• Real-time streaming of flag updates without restarts
• Rich targeting rules, percentage rollouts, and user segmentation
• Feature-level observability and A/B testing capabilities
• Role-based access controls, audit logs, and governance features
• High availability through redundant infrastructure

Popular open-source options include Unleash, Flagsmith, and OpenFeature. Commercial platforms like LaunchDarkly, Harness Feature Management & Experimentation (FME), and Optimizely offer more advanced capabilities around experimentation, automation, and enterprise governance.

Feature Flags Best Practices

Adopting feature flags effectively requires more than just wrapping code in conditionals. Here are best practices drawn from industry experience:

• Start simple, then scale. Begin with boolean on/off flags for your first use cases. As your team matures, introduce percentage rollouts, user targeting, and experimentation.
• Keep flags short-lived by default. Treat every flag as temporary unless it explicitly serves a permanent purpose (entitlements, kill switches). Set an expected removal date when you create it.
• Use consistent naming conventions. Include the team, project, and intent in the flag name (e.g. paymentsTeam-newCheckoutFlow-release).
• Minimize flag scope in code. Place the flag decision at a single, high-level abstraction point rather than scattering if/else checks throughout the codebase. The strategy pattern is a clean way to encapsulate flagged behavior.
• Test all flag states. A feature flag doubles the number of code paths. Ensure your test suite covers both the "on" and "off" states, and test the transition between them.
• Add monitoring and logging around flagged features. When you enable a flag, you should be watching metrics — error rates, latency, conversion — to decide whether to continue the rollout or roll back.
• Control access with role-based permissions. Not everyone should be able to toggle every flag. Use your platform's governance features to define who can modify which flags and in which environments.

Don't use flags for everything. Feature flags are not a replacement for secrets management, static configuration, or database schemas. Use them for runtime behavior control where the ability to toggle, target, or roll back provides clear value.

Feature Flags and Technical Debt

What happens when you have too many flags? Worse still, what happens when your code base is filled with old code hidden behind flags that have effectively turned it off even though it still remains in the code? This is called flag debt, and it’s a form of technical debt that can quickly build up over time but just as easily be avoided by simple hygiene.  The key is to see most flags as temporary — as nothing more than a tool to speed up the development process safely. Since they are temporary, removing them isn’t “extra work” but rather part of the typical lifecycle that makes them valuable.

Temporary vs. permanent flags:

• Temporary flags are used for releases, experiments, rollouts, and migrations. They should be removed once the feature is fully launched or the experiment concludes.
• Permanent flags are part of ongoing operations (e.g. feature gating by customer tier, kill switches for critical infrastructure, or entitlement management). These stay in the codebase intentionally.

Here are some tips for avoiding flag debt:

• Use well-structured self-evident names for feature flags, so other developers will know why they are there
• If you don’t include the project or task id in the flag name, make it easy to “look up” a feature flag by name to see who its owner is and when it was last modified.
• Place flag decisions at natural points of abstraction. Instead of placing them throughout a module, put them in the code that calls the module and have it decide whether to call the old version or the new one. That way, the flag, and the old module can simply be removed and replaced with a direct call to the new module without any complex editing.
• Create a Jira ticket (or whatever task ticketing system you use) to remove a flag as part of the workflow you use for creating it.

Ship Faster and Safer with Feature Flags

Feature flags are no longer a niche practice — they are a core enabler of modern software delivery. When paired with lifecycle discipline and the right tooling, they let teams ship faster and safer at the same time.

Explore Harness Feature Flags to get started.

Frequently Asked Questions About Feature Flags

What is the difference between a feature flag and a feature toggle? 

There is no difference — they are different names for the same concept. "Feature flag" and "feature toggle" are used interchangeably across the industry. Other synonyms include feature switch, feature flipper, and release toggle.

Do feature flags slow down application performance? 

When implemented properly, feature flags have negligible performance impact. Most modern feature management platforms evaluate flags locally using cached configurations, avoiding network round-trips on every request. The overhead is typically measured in microseconds.

Are feature flags only for large engineering teams? 

No. Teams of any size benefit from feature flags. Even a solo developer can use a simple boolean flag to safely deploy incomplete work and test in production. As teams grow, the benefits compound — coordination overhead drops, release risk decreases, and non-engineering teams gain autonomy.

How do feature flags relate to A/B testing? 

Feature flags are the underlying mechanism that powers A/B testing. By assigning different flag variants to different user segments, you can compare behavior and performance between groups. Many feature management platforms include built-in experimentation and statistical analysis on top of their flagging capabilities.

What is the difference between feature flags and configuration files? 

Configuration files are typically edited manually and require a restart or redeployment to take effect. Feature flags evaluate at runtime and can be changed instantly via a management interface — without touching code, pipelines, or servers. Feature flags also support per-user targeting, percentage rollouts, and real-time kill switches, which configuration files generally do not.

How do you prevent feature flags from becoming technical debt? 

The key is lifecycle discipline: treat most flags as temporary, create a cleanup ticket when you create the flag, schedule regular flag review sessions, and use platform analytics to identify stale flags. See the "Feature Flags and Technical Debt" and "Feature Flag Lifecycle" sections above for detailed guidance.