Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Managing Feature Flags at Scale: Categorize Your Feature Flags

DZone's Guide to

Managing Feature Flags at Scale: Categorize Your Feature Flags

With flags categorized, you can be able to distinguish between short-lived and long-lived flags and manage each appropriately.

· DevOps Zone ·
Free Resource

Learn more about how CareerBuilder was able to resolve customer issues 5x faster by using Scalyr, the fastest log management tool on the market. 

Feature flagging systems can sometimes become victims of their own success. The benefits of feature flagging 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.

One way to keep your flags manageable is to introduce a categorization system. This 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 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 flags are managed by different people and have different requirements around configuration change. They also have very different lifecycles. 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 lifecycle of these features is often measured in years.

Managing Different Flags Differently

With 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.

Find out more about how Scalyr built a proprietary database that does not use text indexing for their log management tool.

Topics:
devops ,feature flags ,coding ,toggles

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}