The benefits of feature flags, along with the broad applicability of the technique, can lead to rapid adoption within an organization, and pretty soon the number of active flags can start to feel overwhelming, making the system a victim of its own success. One of the best ways to keep ahead of feature flag management is to introduce a categorization system.
A feature flag categorization system makes ownership of a given flag clearer, and also reduces cognitive overhead by reducing the flags you need to consider at any one time. Most importantly, it will allow you to easily identify flags which will be long-lived versus flags which should be retired quickly.
Categories of feature flags
When a team starts working with feature flags they are typically all thrown into the same bucket. They are all just “flags”. However, in reality there are distinct use cases for different flags. A flag that is used for an A/B test is quite different than a flag used for a canary release, which is quite different than a flag used to place certain features behind a paywall.
Any given feature flag can be placed into one of four toggle categories (covered in more detail in this article).
- A Release Toggle enables Continuous Delivery practices such as dark launching and canary releasing.
- An Experiment Toggle supports A/B or multivariate testing.
- An Ops Toggle controls operational aspects of a system in production. For example, a flag which places a system into read-only mode while a data migration is being performed.
- A Permissions Toggle restricts certain features to certain users. For example, hiding “premium” features from unpaid users or only exposing management features to admin users.
These different types of feature flags are managed by different people and have different requirements around configuration change. They also have very different life-cycles. A Release Toggle flag used for canary release will only need to be around while a feature is actively being released. Once it has fully rolled out the flag can be retired. The life-cycle of Release Toggle flags are typically on the order of days or weeks. In contrast, a Permissions Toggle flag which protects premium or admin features—features that only certain users are allowed to access—will likely be around for the entire life of that feature. The life-cycle of these features is often measured in years.
Managing different feature flags
With feature flags categorized we are able to distinguish between short-lived and long-lived flags, and manage each appropriately.
For short-lived flags, we should be aggressively enforcing their retirement, in order to reduce the total number of active flags in our system. In a future post we’ll discuss some concrete approaches that can be used to ensure flags are actually retired.
For long-lived flags, we should be paying close attention to how the flag is implemented. We do not want to litter conditional statements throughout our codebase if this flag is going to be in place for perpetuity. Instead, we might consider using techniques like Dependency Injection and the Strategy pattern to keep our code understandable and maintainable.
If you’re looking for a deeper dive on how to successfully separate feature release from code deployment at scale, we hosted a live webinar on February 21, 2018 with the author of this article, Pete Hodgson. Pete expanded on feature flags, feature flag management, and continuous deployment best practices—with a Q&A that followed afterwards. Watch the recording of the webinar now.
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
In this tutorial you’re going to create a CoffeeBot app. The app will have a Vue.js client and a Spring Boot resource server, bootstrapped using JHipster.
At Split, we “dogfood” our own product in so many ways. Our engineering and product teams are using Split nearly every day. It’s how we make Split better.