What are feature flags in DevOps [2023]

Feature flags (also known as feature toggles or feature switches) are a software development technique that allows teams to enable or disable specific features or functionality in their applications at runtime.

Feature flags can be useful for a number of use cases:

  • A/B testing. Feature flags can be used to enable or disable different versions of a feature for curated users. Teams can use feedback to gauge the effectiveness of different approaches and reiterate.
  • Progressive rollout. Feature flags can be used to gradually roll out new features to a subset of users. Teams can test a feature in a production environment and gather feedback before making it available to all users.
  • Feature management. Feature flags can be used to manage both the development and deployment of new features. Team members can turn features on or off as needed without having to redeploy an entire application.
  • Disaster recovery. Feature flags can be used to quickly disable a feature as needed using tools such as a kill switch. This minimizes the impact on both users and the organization deploying the feature.

Overall, feature flags can help teams to be more agile and responsive. Teams gain the ability to quickly enable or disable specific features in their applications at runtime.

To branch or not to branch

But what about feature branches?

Feature branches have been a pattern to handle new feature development for quite some time. Essentially, a feature branch is a copy of the source code where one or more developers build a new feature.

This is a safe way to work because you can be sure that no untested code gets into production.

Even a simple merge can be complex

In practice, a developer writes code in their separate branch until they’re confident that the feature is complete and ready to be merged back into the main branch. The code is fully isolated as long as the feature branch is live.

Feature branches are complicated

However, there are a few drawbacks to using feature branches. For one thing, they exist outside of the main branch, which is where the service or application that end users interact with lives.

This means that, for a feature to be enabled, it has to be merged into the main branch. This can be complex, especially if many developers have been working on the main branch while the feature branch was being developed.


Traditional merges and syncs can take up a lot of time

To try and avoid merging complexity, some teams use different branching strategies.

For example, they might sync changes from the main branch into the feature branch on a regular basis. The idea is to reduce the complexity of merging the feature branch back into the main branch.

However, the team working on the feature branch still needs to spend time making sure their branch is up-to-date with the main branch. Maintenance time takes away from development time.

Another issue with feature branches is that it can be hard to share code between parallel feature branches. This is often the case when a new feature has dependencies. In this situation, a developer needs to test the two feature branches together as early as possible.

However, if the features are being developed in separate feature branches, end-to-end testing usually happens very late in the process. This often leads to a significantly longer time-to-market for the new feature.

Feature flags keep it simple

In their most basic form, feature flags are simply an if-statement that protects a new feature. They’re used to disable a new feature that has been put into the production environment for all or most users, usually because the feature isn’t fully complete yet.

A development team may want to validate the software in the production environment before making it available to all users.

if (unleash.isEnabled("AwesomeFeature"))
  // some new magic 
  // old boring stuff 

Many development teams start using feature flags as a home-brewed solution as an alternative to feature branches. The benefit of using feature flags is that the new feature stays in the main branch while it’s protected from end-user exposure.

That said, there are a couple of drawbacks to using simple if-statements as feature flags.

First, a developer would have to trigger another code deployment on production to change the state of the feature flag. This can be addressed by, for example, setting the feature toggle state in a separate configuration file.

Second, you probably couldn’t change the feature toggle state without a developer.

Feature flags in DevOps

In the world of DevOps, feature flag management is becoming more popular. This raises the question: should you extend your homemade feature flags solution to support complex scenarios, or should you focus on your core business and buy a tool?

It’s the classic make-or-buy decision that all engineering organizations face at some point:

Is developing feature flags solution part of your core business?

Feature management solutions like unleash provide advanced activation strategies out of the box.

One important and common activation strategy is to activate only for given users. We call this strategy userWithId.

Another popular activation strategy is Gradual rollout. This strategy is for when you want to activate a new feature for a small portion of your end-users, say 1 percent.

You can find more examples of activation strategies in our blog post on strategy constraint operators.

An Unleash project with three active toggles.

A feature flag solution should also provide a professional management dashboard for easy updates to feature toggles.

In the blog post Feature flag best practices your team should adopt today, we focus on how management practices are a critical and important part of industry best practices.

This includes making the feature toggles easily accessible to key people in the development process. They should also be accessible to team members outside of the development team, like a product owner or product manager.

A feature management solution should also keep a full audit log of changes to the feature flags since they can become a critical part of your release strategy. It’s important to keep track of who made what changes when feature flags are a key part of your process.

Proper UI and user admin

Even in the post-feature-game era, features are key to a software product. Managing the roll-out of these features is essential.

In many cases, it also makes sense to allow non-developers to control feature enablement. Again, this could include product managers, product owners, or a similar roles.

Management UIs that come with feature management solutions like Unleash give easy access to feature flags. This gives admin abilities like user management, access control, and approvals.

Find out for yourself what open-source feature management can do


Updated April 2023

Share this article