A feature toggle, (also feature switch, feature flag, feature flipper, conditional feature, etc.) is a technique in software development that attempts to provide an alternative to maintaining multiple source-code branches (known as feature branches), such that the feature can be tested, even before it is completed and ready for release. - Wikipedia
Feature toggles are a powerful way of postponing the activation of features in a continuous delivery workflow.
There are advantages to developers working using this pattern, for example: all the merge problems go away and it reduces deployment risk through canary releases or other incremental release strategies. All of this makes it easier to get new code out faster for testing and feedback. The main disadvantages is that feature flags make the code more fragile, harder to test, harder to maintain and less secure. In fact, feature flags need to be short-lived, the main purpose of toggles is to perform release with minimum risk. Once release is complete toggles need to be removed.
Feature toggling is very useful when you want to keep the production code very close to the development version, when the business isn't ready for the feature to be enabled or when you want perform an canary release of your code. Important: do not use feature toggling to enable code that is not complete. Feature flags introduces a lot of complexity in your code.
Feature toggling pattern is usually implemented by three different components:
- Toggle point: is the component which call the toggle router;
- Toggle router: contains the logic to check if a certain toggle point is active or not. Toggle router reads toggling configurations to detect features or simply detect an Toggle Context. For example a special cookie or HTTP header.
- Toggle configurations: contains the informations about the active/deactivate toggle points. Usually, toggle configurations, are environment-specific;
Categories of toggles Feature toggles can be categorised by using different params: the longevity of the feature and how dynamic the toggling decision must be.
- Release toggles: separate feature release from code deployment. Release toggles allow codepaths to be shipped to production as latent code;
- Experiment toggles: perform multivariate or A/B testing. This technique is commonly used to make data-driven optimizations to things such as the purchase flow of an e-commerce system, or the call to action wording on a button. An Experiment Toggle needs to remain in place with the same configuration long enough to generate statistically significant results;
- Ops toggles: ops toggles will be relatively short-lived - once confidence is gained in the operational aspects of a new feature the toggle should be retired;
- Permissioning toggles: change the features or product experience that certain users receive. For example we may have a set of "premium" features which we only toggle on for our paying customers;
There are different way to change and manage feature toggle flags:
- Compiled: the flag value is written in the code, hardcoding doesn't allow dynamic re-configuration of a toggle;
- File: you can read toggle configurations inside a structured file, for example a JSON file, you can now re-configure a toggle by simply changing that file rather than re-building application code itself;
- Parametrised: the toggle configurations are passed as command-line arguments or query string parameters. You need to pass the configurations every time;
- Database: you can store configurations inside a database. Usually, it is combined with some form of admin UI which allows system operators, testers and product managers to view and modify Features Toggles and their configuration;
This article shows how to implement Feature toggling using ASP.NET.
Feature toggling is very useful technique in the continuos delivery stack. I suggest to use it with care, because each Toggle introduces technical debt inside our code. Here are some useful link about feature toggling:
- Martin Fowler - Feature Toggle
- Feature Toggles are one of the worst kinds of Technical Debt
- Decoupling Deployment and Release- Feature Toggles