What is a feature flag?

At a basic level, feature flags take the form of simple conditionals (e.g., if-else statements) that determine the code path that will be executed. Feature flags determine at runtime which portions of code are executed. This lets you deploy new features without making them visible to users, or you can make features visible only to specific subsets of users and environments.

Decoupling deploy from release

Historically, deploy and release were synonymous because code that was deployed to the production environment was automatically running in production. This meant that every new deploy carried significant risks to the existing application. As a way to mitigate these risks, teams would bundle multiple features into releases that might happen once a week, once a month, or even once a quarter. However, this actually raised the stakes of a deploy significantly and, if any single feature was broken in production, the entire bundled release needed to be rolled back, dramatically slowing down the velocity of development teams.

Feature flags change the traditional deployment workflow by decoupling deploy and release, allowing new code to exist in a production deploy but not be executed and, therefore, not released (aka a dark launch). This provides a safety net that enables teams to both lower risk and deploy more frequently. That is, teams increase speed and stability, a hallmark of high-performing engineering teams, according to the Accelerate: State of DevOps Report.

How feature flags change software delivery

In separating deployments from releases, feature flags dramatically change the way development teams operate:

Trunk-based development

With flags, you don't have to maintain multiple long-lived feature branches. Whether you use GitHub, GitLab, or some other solution for your CD pipeline, long-lived branches frequently cause complex merge conflicts that lead to hard-to-debug issues. Feature flags enable trunk-based development, a practice in which development teams all work in the main branch and/or frequently merge short-lived branches. This removes the complexity of merges and enables teams to move faster by allowing them to deploy code changes continuously. (See our deep-dive on Git branching strategies vs. trunk-based development.)

Manage the feature lifecycle

Controlling who has access to a feature enables teams to control the full lifecycle of that feature. For example, a feature flag can make new features available only to a subset of users for testing and feedback before being released publicly. Or a release can be timed to align to with a marketing campaign without requiring a deploy or even intervention by engineering at all. Simply flip the flag and the feature is live with the full confidence that the success of the campaign will not be undermined by a failed or delayed deployment.

Remove the stress and risk around software releases

Feature flags reduce the stress around releases by allowing faster resolution of incidents (i.e., mean time to remediate, which is a key DORA metric). If a feature is causing problems, turning off the corresponding flag will disable it, solving the problem immediately without the need to roll back a complex release that may contain multiple critical features or fixes. Feature flags even enable Progressive Delivery, whereby a feature is gradually released to larger populations of users to ensure that it performs as expected.

Feature flags are NOT configuration files

Generally, when you use configuration files to change the behavior of your software, you have to manually go into a file, change an environment variable, and then push the change through your deployment pipeline. But feature flags—in a platform like LaunchDarkly—evaluate in runtime. You flip a switch, and the change occurs instantly without you needing to redeploy, restart, or wait.

Also, config files act as blunt on-off switches for all users. Whereas, feature flags enable precise targeting and control, letting you roll out specific changes to specific audiences.

Point being, feature flags are more versatile, sophisticated, and powerful than config files.

Feature flags and CI/CD

As you may have noticed, feature flags and continuous integration/continuous delivery go hand in hand. With continuous integration, development teams are encouraged to merge code into a main branch of the repository.

Traditionally, the number of feature branches tended to grow exponentially as the development team expanded. The longer each branch lived, the more out of sync it would become with the main branch and with feature branches belonging to other team members. Integrating these branches was frequently extremely painful. Continuous integration helps teams solve this problem by enabling them to merge frequently, with automated testing processes that helped prevent “breaking the build.”

The issue becomes, how do you combine frequent merges with feature development that may take days, weeks or even months without breaking the build? This is where feature flags come in. They allow you to define which code paths will be executed and which will be ignored. This allows teams to combine short-lived feature branches with longer running feature development.

Who uses feature flags?

Since feature flags are implemented in code, they require a development or engineering team to configure them within the application. As a result, software developers are typically the first to adopt feature flags for managing feature releases. However, that does not mean that their utility is limited to development or engineering teams.

Feature flags are the underpinning of a feature management solution, which enables teams across the company to perform tasks that previously required engineering intervention. For example, utilizing a feature management platform with feature flags can enable:

• QA to test functionality in production and validate changes.
• Sales and Customer Support to provision entitlements.
• Product Management to manage which end users get beta program access or align releases with non-engineering business priorities.
• Marketing to run A/B tests or time releases to campaigns.

Pairing feature flags with a feature management platform makes toggling flags easy to understand can enable release stakeholders across the company to contribute to the release lifecycle.

Feature flag use cases: When to use flags

There are several common feature flag use cases.

De-risk software releases (release management)

Using flags as part of your build or feature release process is one of the most common uses of feature flags. Release management includes early access programs, canary releases, and beta programs—anywhere you give specific users access to features before releasing the feature to everyone. Starting small and rolling out to larger groups over time helps you:

• Observe the behavior of the systems and services under increasing load.
• Collect user feedback and make changes if you need to.
• Limit the blast radius if something goes wrong

Improve reliability and operational health

Feature flags can manage and control the behavior of a system toggling a feature on/off to minimize the impact of incidents. Using operational feature flags you can:

• Deploy circuit breakers or kill switches to programmatically or manually disable a feature if it negatively impacts the user experience and alerts are triggered.
• Limit API requests to ensure API reliability.
• Switch to a less feature-rich version of a page under heavy load.
• Test migrations to new microservices or third-party dependencies in production for interoperability testing.
• Change log-levels on the fly for debugging purposes.

Target and personalize software experiences

If you use feature flags with a targeting engine (like LaunchDarkly's), you can release specific features and experiences to specific audiences. With targeting, you can:

• Personalize software experiences based on user preferences
• Tailor features to users' mobile device and app version
• Deliver targeted experiences based on region, geography, etc.
• Gradually roll out features to target segments, starting with internal testers
• Automate feature entitlements

In software, entitlement refers to the right to use services, products, or features. Entitlements define the features each user can access. Feature flags, in the context of a feature management platform, can empower others in the organization to manage and control entitlements, even within a multi-tenant SaaS environment. This results in better customer experiences and greater operational efficiency.

Learn through product experimentation and A/B testing

Monitoring and observability tools can tell you if a feature isn't working correctly, but they can't tell you if you if you built the right feature. Experimentation or A/B testing can offer insights into things like how users are using your feature and/or whether it is performing as intended to ensure you release the correct feature.

Using feature flags, you can test different configurations of a feature to validate or disprove hypotheses. Experiments provide concrete reporting and real world measurements to ensure that you are launching the best version of a feature that positively impacts company metrics. Sue to the complexity of implementing experimentation, in most cases it requires the use of a feature flag service or feature management platform.

Reduce the risk of migrations

Infrastructure, cloud or software migrations are inherently high risk, so much so that often teams will avoid or postpone necessary migrations. Feature flags can be used to help mitigate the risk of infrastructure migrations or avoid downtime in a cloud migration. Combining infrastructure migrations using feature flags with progressive rollouts can help ensure that the change doesn’t degrade performance. Some feature flag services like LaunchDarkly can even integrate directly with monitoring and observability platforms and automatically trigger a kill switch if specific performance thresholds are crossed.

Here Gene Kim, a popular DevOps author, researcher, and founder, explain how to use feature flags for technology migrations.

How are feature flags deployed?

How you choose to deploy feature flags depends on several factors including:

• The size of your engineering team
• How often you perform code deployments to production
• How many flags you want to deploy
• Whether you want to build vs. buy

Many companies start using feature flags via a configuration file, often created in environment variables, a markup language like YAML, or configuration values in a service like AWS AppConfig. This type of homegrown solution works well for flags that are either "on" or "off" for your entire user base. However, it does require developer intervention to change a flag and, in the case of a physical config file, it may require a redeploy of changes. Also, because using config files can get too long, it tends to be a better solution for project that only want a small number of flags.

For a large number of flags, or for more complex homegrown solutions that may include a management dashboard, you'll likely opt to store flags in a database. Depending on the complexity of your solution, this method can allow features to be targeted to individual users. You also can make modifications to user targeting without having to restart or re-deploy services. However, any management tools or targeting logic would need to be created and maintained in-house. In addition, the solution may lack the ability to push changes back down to the application so that, for instance, if a kill switch is flipped, the effect is immediate.

There are some open-source feature flag management solutions available as well as a vendor neutral solution called OpenFeature from the CNCF. Most open source solutions typically allow for user segmentation, targeting, and controlled feature rollouts and include some form of management dashboard, but some solutions may be language or framework specific, which may not allow for flag usage across projects that include multiple languages.

A final deployment option is to use an enterprise feature flag platform or feature management solution like LaunchDarkly. When you have needs such as role-based access controls (RBAC), audit logs, streaming updates, or use cases including experimentation or entitlements, you would want to deploy a comprehensive feature management solution. Another benefit is that platforms like LaunchDarkly provide a range of language and framework SDKs that can make it easier to adopt flags into your development process.

Feature flags and technical debt

As we’ve noted, feature flags offer many benefits to development teams. However, they can incur technical debt that is often referred to as flag debt, especially as a team adopts them more broadly. Flag debt is where your code becomes littered with flags and old code that are no longer useful because the feature has been rolled out to the entire user base.

There are a number of ways teams can manage flag debt. It starts with a proper naming strategy so that the purpose of a flag is clear. Feature flag platforms and services like LaunchDarkly often include analytics that can assist in determining if a flag is still in use. It is a best practice for development teams that have widely adopted feature flags to regularly assign a day, whether monthly or quarterly, for flag cleanup.

Why use LaunchDarkly for feature flags?

LaunchDarkly offers a feature management platform as a service designed for the entire organization. While you can choose to go the homegrown or open source route to get started using feature flags, LaunchDarkly provides a number of critical benefits that will both ease your adoption and integration of feature flags but also increase the capabilities of them over the homegrown or open source alternatives.

• LaunchDarkly provides 25+ SDKs for front-end, back-end, and mobile that make integration into almost any project easy, regardless of the languages it is built with or the platform it is built for. This also makes it easy to integrate on both the front-end and backend of your application.
• LaunchDarkly is designed to scale. Initial flag evaluation occurs in less than 25ms. The results are cached for even faster subsequent evaluations while any flag updates are streamed to connected clients within 200ms. This means, for instance, that if you flip a kill switch, the effect will be near immediate.
• LaunchDarkly provides a ton of advanced features that are hard to replicate in homegrown or open source systems including advanced targeting, big segments, experimentation and workflow automation.
• LaunchDarkly includes integrations with many of the products and services you already use including Datadog, Honeycomb, New Relic One, Slack, Jira Cloud, ServiceNow, Cloudflare, Terraform, Zapier and many more.

We believe the effective use of feature flags is an organization-wide endeavor, not something limited to a few developers. LaunchDarkly grows with you as your feature flagging practice expands from a single flag deployed by a single developer to team-wide use, to delegating control of flags to other teams to meet their use cases.

Feature flag resources

Check out these additional resources on feature flags, feature management, best practices, DevOps, progressive delivery, and more!

Feature Flags Content Hub
LaunchDarkly YouTube Channel
LaunchDarkly Website - Feature Flags, Feature Management, and Experimentation
Feature Flags and AI

You can also request a demo of the LaunchDarkly feature management platform or start a free trial.