dynamism - how dynamic the toggling decision must be
who will manage the feature toggle
Release Toggles
allow incomplete and un-tested code paths to be shipped to production as latent code which may never be turned on
are transitionary by nature. They should generally not stick around much longer than a week or two
Experiment Toggles
are used to perform multivariate or A/B testing
this technique is commonly used to make data-driven optimizations
highly dynamic
needs to remain in place long enough to generate statistically significant results
Ops Toggles
are used to control operational aspects of systems’ behavior
introduced when rolling out a new feature that has unclear performance implications so that the system operators can disable or degrade it in production if needed
relatively short-lived
however, it may be long-lived “kill-switches” that allows system operators to gracefully disable/degrade non-vital functionality when the system is enduring unusually high load (manually-managed Circuit Breaker)
purpose of these flags is to allow operators to quickly react to production issues they need to be re-configured extremely quickly - needing to roll out a new release in order to flip an Ops Toggle is unlikely to make an Operations person happy
Permissioning Toggles
used to change the features or product experience that certain users receive (e.g., premium users)
/feature-toggle-categories.png)