Unleash

What is a feature toggle service?

A feature toggle service allows you 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 a proper audit trail in case there are some issues introduced.

Branch or not to branch…

Feature branches have 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 does 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 the 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. The 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. Especially if there are many developers that have 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 of merging the feature branch back into the main branch. Still, the team working in the feature branch still needs 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 its simplest form, a feature toggle is an 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 
}
  else 
{ 
  // old boring stuff 
}

It is quite common that development teams introduce 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 to 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 question 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 a tool? The typical make-or-buy discussion all engineering organizations tend 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” are a critical and important part of what is considered best practices. This makes the feature toggles easily available to key people in the development process as well as those outsides of the development team. Examples are the Product owner and the Product manager. A professional feature toggle service also needs to keep a full audit log of changes to the feature toggles. When feature toggles start 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 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 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.

Want to try Unleash?

GET STARTED TRY OUR DEMO

Share this article

Explore further

Illustration of DevOps
Community

Here’s how decoupling deployment and release can bring value to your business

Read more