🚀 Unleash brings powerful Constraints feature to OSS users. 

Read more →

What are feature flags?

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. This can be useful for a variety of purposes, including:

  • A/B testing: Feature flags can be used to enable or disable different versions of a feature for different users, allowing teams to test the effectiveness of different approaches and gather feedback.
  • Progressive rollout: Feature flags can be used to gradually roll out new features to a subset of users, allowing teams to test the feature in a production environment and gather feedback before making it available to all users.
  • Feature management: Feature flags can be used to manage the development and deployment of new features, allowing teams to turn features on or off as needed without having to redeploy the entire application.
  • Disaster recovery: Feature flags can be used to quickly disable a feature in the event of an emergency or unforeseen problem, minimizing the impact on users and the organization.

Overall, feature flags can help teams to be more agile and responsive by allowing them to quickly and easily enable or disable specific features or functionality in their applications at runtime.

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 work to develop a new feature. This is a safe way to work because you can be sure that no untested code gets into production.

Feature branch
You develop your code in your separate branch until you are confident that the feature is complete and ready to be merged back into the main branch. Your code is fully isolated as long as the feature branch does 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 to enable a new feature, you have to merge the feature branch 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.
Keeping feature branches in synch is hard
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. This can help 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, which can take time away from actually developing the new feature.

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 depends on other new development. In this situation, you need 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 leads to a longer time-to-market for the new feature, which isn’t ideal.

Feature Flags: Simplicity vs. Complexity

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. The 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. There are a couple of drawbacks to using simple if-statements as feature flags, though. First, you have to do another code deployment on production to change the state of the feature flag. This can be addressed by setting the feature toggle state in a separate configuration file or something similar. Second, you need a developer to change the feature toggle state whenever it’s needed.

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?

Unleash feature flags tool provides 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, and popular activation strategy is Gradual rollout. Gradual rollout allows you to activate the new feature to a small part of your end-users, say 1%. We present more examples of activation strategies in our blog post on strategy constraint operators.

Unleash is a feature flag management solution that provides advanced activation strategies out of the box. One common activation strategy is to activate the feature only for certain users (we call this the “userWithId” strategy). Another popular activation strategy is Gradual rollout, which allows you to activate the new feature for a small percentage of end users (e.g. 1%). We’ve written more about activation strategy constraint operators in a previous blog post.

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 What are feature toggle best practices? it is clear that “Management practices” are a critical and important part of what is considered best practices. This includes making the feature toggles easily accessible to key people in the development process, as well as those outside of the development team (such as the product owner and product manager). A professional feature flag 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 area, 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 the feature enablement. This could be the Product Manager, the Product Owner, or similar roles. To provide easy access, a management UI is excepted to support such a use case. A feature toggle service will provide such a feature management UI. Along with this, a feature toggle service will also provide proper user management. This is to handle who got access and what access. Maybe some users should only have read access. Usually, this could be supported to allow them to see the status of a certain feature in production.

Even after a feature has been released, it’s still important to manage the rollout of new features. This is where a user interface (UI) and user administration come in. In many cases, it makes sense to allow non-developers (such as the product manager or product owner) to control the enablement of features. A feature flags solution should provide a management UI to support this use case, as well as proper user management to handle access and permissions. Some users may only need read access, for example, so they can see the status of a particular feature in production.

Want to try Unleash?


Share this article