Mastering Feature Flags: Types of Feature flags
This article is part of a series, if you got here first, it might be worth it to check the previous one first:
This article delves into the various types of feature flags, a powerful technique that allows teams to modify system behavior without changing code. Understanding the different types of flags — Release, Experimentation, Operational, and Permission — is crucial for effective feature management. Whether you’re a developer, a product manager, or a system administrator, this guide will help you comprehend the utility and application of each flag type.
Types of Feature Flags
Categorizing feature flags helps in better management and understanding of their purpose.
The main classification is based on the flag’s purpose:
- Release Flags
- Experimentation Flags
- Operational Flags
- Permission Flags
Two additional dimensions are time: short/long-lived and scope: user/system-based.
- short-lived — flag exists for a single release/experiment cycle
- long-lived — flag exists for multiple (but still limited) release cycles
- user-based — flag directly affects UX and what users see
- system based — flag is controlling the operational aspect of the application
Release flags
They are also known as release toggles and separate feature deployment from feature release. Using them correctly allows engineers to merge code to the main code base and deploy it to production without changing the application behavior. Once the feature is thoroughly tested and signed off for release, the flag can be toggled to make it available for all users.
- Purpose: to decouple the process of deploying code from releasing it to end-users.
- Application: phased rollouts and canary releases, allowing engineers to expose new features to a small user base before a full-scale launch.
- Stakeholders: software and QA engineers are the primary users of this type of flag. Engineers can merge code without affecting production, while QA teams use them to test new features in a live environment.
Experimentation flags
They are often used in A/B testing and allow engineers to expose different versions of a feature to other groups of users. They are a valuable instrument to verify how users perceive feature changes, their impact on their behavior, and our bottom line. The key requirement with experimentation flags is to capture data about the exposure and which user got what.
Various stakeholders can then use data gathered during such experiments to make informed decisions about direction. Different stakeholders could perform such experiments for other purposes, such as engineering, comparing different content searching, or sorting algorithms.
- Purpose: used for A/B testing and feature experimentation by allowing user groups to experience different feature sets.
- Application: optimizing user experience or comparing different algorithms (i.e., engagement with new chat vs. old chat).
- Stakeholders: product managers set the criteria for A/B tests, while data analysts evaluate the results to inform future development.
Operational flags
They are used to control the operational aspects of a system. They are handy for managing system behavior during different conditions or incidents. Operational flags are strictly system-based flags and should affect the application as a whole. They are instrumental during migrations from one back-end to another, or gradual adoption of a new type of service, etc. Other examples could include changing log level, throttle calls to the back-end to manage system load, enabling/disabling debug and maintenance modes, etc. However, these should be limited in scope and targeted towards a specific function of the application, such as while migrating to a new SSO provider; it could be helpful to be able to change the log level or throttle calls. This shouldn’t be the practice for features or system behavior that is considered standard.
- Purpose: control system behavior.
- Application: dynamically adjusting system logging levels without requiring restarts, toggling maintenance, or limited functionality mode during incidents, etc.
- Stakeholders: DevOps teams use the flags to manage system behavior during incidents, while system administrators may use them for routine maintenance tasks.
Permissions flags
They control access to features based on user segmentation, which allows for fine-grained control over who and what they can access. Example: Early adopter users’ segment gets a new product experience; VIP customers get a different deposit experience, etc. These flags also enable engineers to test on production without affecting the general player population.
- Purpose: control feature access based on user roles or segments.
- Application: early access, beta testing, customized user experience based on user segment.
- Stakeholders: product managers may set these flags to segment user access, while customer success teams can toggle them to provide premium features to specific accounts.
Summary
In summary, feature flags offer a versatile approach to dynamically managing features and system behavior. We’ve explored four primary types of flags: Release Flags for decoupling deployment from release, Experimentation Flags for A/B testing, Operational Flags for system management, and Permission Flags for user-based access control. Knowing when and how to use these flags can significantly enhance your software development lifecycle, providing flexibility, reducing risk, and enabling data-driven decisions.
This article is part of a series, if you enjoyed it you should check out some of the other parts as well:
- The basics
- Types of feature flags (you are here)
- Life cycle
- Testing feature flags
- Risk mitigation
- Performance and Resilience
Want to learn more about DraftKings’ global Engineering team and culture? Check out our Engineer Spotlights and current openings!
