What is a feature toggle service?

A feature toggle service allows you with a simple way to manage and control your new feature post-production. It simplifies some of the hurdles experienced with feature branches. Also, a feature toggle service will take care of proper audit trail in case there are some issues introduced.

Branch or not to branch…

Feature branches has been a pattern to handle new feature development for quite some time. At its core, a feature branch is a copy of the source code, where one or more developers work to develop the new feature. It is safe, because you are sure that no untested source code do hit 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 main branch. Your code is fully isolated as long as the feature branch does live.


Feature branches are complicated

One of the biggest drawbacks with feature branches, is that it by definition exists outside of the main branch. Main branch is where the service or application that the end users exists. This means that to enable the new feature, the feature branch needs to be merged into the main branch. This is often a complicated effort. Specially if there are many developers that has worked on the main branch in parallel with the feature branch, a scenario that is quite common.

Keeping feature branches in synch is hard

Different branching strategies often are applied to avoid the merging complexity. One common strategy is to synch the changes in main into the feature branch on a regular basis, e.g. once a day. This can take away some of the complexity merging the feature branch back into main. Still, the team working in the feature branch still need to spend time making sure their feature branch is up-to-date with the main branch. This is time they could spend on developing the new feature.

Sharing code between parallel feature branches is often complicated. This is another common drawback with feature branches. Usually it is the case that a new feature depends on other new development. This means that there is a need to test the two feature branches together as early as possible. As the two features are developed in two separate feature branches, this usually leads to that the end-to-end testing happens very late in the process. This should be avoided because the lead-time from the developed to the code is tested is significant, maybe weeks. This increases the time-to-market for the new feature.

Feature toggles – in it’s purest form

In it’s simplest form, a feature toggle is a if-statement protecting some new feature. The purpose of the feature toggle is to disable a new feature that is put into the production environment for all or most of the users. The reason for doing this, is usually that the feature is not yet complete. The development team may have decided to validate the software in the production environment before making it available to all of the users.

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

It is quite common that development teams introduces feature toggles as a home-brewed solution. Often as an alternative to feature branches.

The benefit of using feature toggles compared to feature branches are clear; The newly developed feature stays in the main branch, while it is protected from end-user exposure. There are particular two drawbacks having the feature toggles as simple if-statements in the source-code. First and foremost, you need to do another re-deployment of your code to production to change the state. This can be handled by setting the feature toggle state in a separate configuration file or similar. Second, you need to ask a developer to change the feature toggle state whenever this is needed.

Feature toggle service

More complex scenarios are requested as feature toggles gain more popularity in the development team. Now a critical questions arises: Should you extend the home-brewed feature toggles into supporting rich and complex scenarios? Or should you focus on your core business and buy such tool? The typical make-or-buy discussion all engineering organizations tends to run into regularly.

Is developing feature toggle services part of your core business?

A feature toggle service 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 on activation strategies in our blog post on How to handle risk in a digital transformation at high speed.

Feature toggle management UI

A feature toggle service, also provides a professional management dashboard for easy updates of the feature toggles.

In the blog-post What are feature toggle best practices? it is clear that “Management practices” is a critical and important part of the what is considered best practices.This makes the feature toggles easy available to key people in the development process as well as those outside of the development team. Examples are the Product owner and the Product manager. A professional feature toggle service also need to keep a full audit log of changes to the feature toggles. When feature toggles starts to be a key part of your release strategy – it is important to keep track of who did what changes.

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 are essential. In many cases, it also makes sense to allow non-developers controlling 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 use case. A feature toggle service will provide such feature management UI. Along with this, a feature toggle service will also provide with proper user management. This to handle who got access and what access. Maybe some users should only have read-access. Usually this could be support to allow them to see the status of a certain feature in production.

Share this article

Explore further


Why feature toggles brings business value

In this blog post we will look at why feature toggles brings business value into DevOps, and how. We are getting used to have the same software development team taking care of both the development and the operations of the services — it makes perfect sense to have the ones that develop the service, also […]

Read more
Industry Insights

Take control of your sprint delivery

A feature management system such as Unleash can give you full control of your sprint delivery. In this article we will explain why and how. Imagine it is sprint demo day and you feel the excitement in the room. Your team committed to 10 user stories in the beginning of the sprint three weeks ago, […]

Read more