Â 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.
Pros and cons of feature toggling
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.
When use feature toggling?
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 toggleÂ components
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;
Feature toggling in practice
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
Top comments (2)
Thank you for your article, simple and clear.
I'm partial because I write the FF4J library but i would like to amend with some elements :
Pleassse Feature Toggle is not ONLY some technical debt, it can easily introduce dynamic behaviour in your application.(Rules) You are able to create some Toggle Points and enable it based on business rules.
If you decide to tag your code with featureName the feature toggle framework can provide you some monitoring (how many do the features has been called, from who, from where...)
Toggle may introduce complexity you're right, but there are patterns to avoid mixing code flipped and other code : AOP annotation and different methods implementation for instance
What about dynamic feature toggles from environment variables or user_id?