Feature toggles

A feature toggle is a software technique that offers an alternative to the use of multiple large branches in the source code (feature branches). In this way, a merge disaster can be avoided, and certain features can be tested before their release. It is a powerful way to disconnect a feature release from the deployment schedule. The lifespan of toggles is best kept as short as possible. As soon as the feature is complete and the toggle is no longer used, it should be removed.

Definition A feature toggle is a powerful technique, allowing teams to modify system behavior without changing code. A mechanism that enables deployment of features that are not finished yet, or of which the quality is uncertain. Code can be deployed to the production environment without being available to the users by turning off the feature toggle. At a later stage it can be made available by just turning the feature toggle on. And if a problem occurs it can be turned off again. (Also called feature flag.)

Feature toggles can be split into four categories depending on the lifespan and the dynamics [Fowler 2017]:

• Release toggle
  A release toggle serves to disconnect the feature release and the deployment schedule. It also prevents the use of feature branches and additional merge difficulties. Release toggles are generally short-lived and should be removed as soon as the feature is ready and the toggle is no longer used. Release toggles are not very dynamic, they are usually configured in one place and are switched on or off for the entire application.
• Experiment toggle
  An experiment toggle controls turning experimental features on or off. A perfect application for an experiment toggle is to perform:
  • a Canary release
    A feature can be made available to a limited subset of users.
  • A / B testing
    By collecting data from both groups of users (the users with and the users without the feature) useful statistics can be compiled to estimate the success of the feature.
• An experiment toggle has a longer lifespan than a release toggle but should also be removed after the test is over and the feature is made available to all users. The toggle is also more dynamic: it can be determined at user level or even by the users themselves.
• Ops toggle
  An ops toggle can be seen as a circuit breaker for non-essential functionalities. Features with a large performance impact can, for example, be switched off dynamically when the application experiences a high load. Another example is whether to use links to external parties that may cause instability. The ops toggle has a longer lifespan and lasts as long as the application or feature exists. In terms of dynamics, the ops toggle can be placed in the middle. The toggle can be switched on or off by several people, e.g. on an admin page.
• Permission toggle
  The permission toggles, or business toggles, are used to make specific parts of the application accessible to a specific set of users. These should not be confused with authorization rules, however. For premium users you can, for example, make a feature available early. It then concerns a predetermined subset of users. As a comparison: an experiment toggle concerns a random group. The lifespan of a permission toggle is average and, as with an experiment toggle, should be removed as soon as the feature is made generally available. When a long lifespan is assumed, it is better to look at the possibility of incorporating it into the authorization rules.