Define Feature Flag type
Problem to solve
Feature flags may be used for different use cases. For example:
- Percent Rollout would be used for features that we wish to deploy to production but want to do it gradually, when the rollout hits 100% the feature flag is no longer needed and the feature is rolled out for all users.
- Feature by subscription. Users may want to enable feature for a paid tier and disable for freemium. This feature flag would be in place forever
There should be a way to distinguish between these two feature flag types.
Intended users
Feature flag users
User experience goal
The user will be able to easily differentiate between feature flags to more efficiently find and manage their feature flags.
Proposal
Acceptance criteria
- We will define the following types of feature flags:
- Release - For teams using Continuous Delivery with trunk-based development to identify a release.
- Experiment - To identify feature flags used for multivariate or A/B testing of experimental features.
- Operation - To identify feature flags that control operational aspects of a system's behavior.
- Safety switch - To identify feature flags that are implemented so that features can be disabled quickly and safely if performance or security impacts are found.
- Access - To identify feature flags that change the features or product experience that certain users receive.
- The table view will show each type with a badge featuring a tooltip
- Tooltip copy:
Feature flag type [INSERT TYPE DESCRIPTION]
- Tooltip copy:
- The edit view will feature a dropdown selection UI including a description for each row.
Table view
Mockup (browser made) |
---|
Edit view
Mockup (browser made) |
---|
Dropdown
Mockup (Figma document |
---|
Further details
This feature flag type will be used later for monitoring and auto management of the feature flags.
Competitors use this terminology: temporary
flag and permanent
flag
For example: when we will implement auto remove feature flag, this would only work on the temporary flag types but will disregard the permanent ones.
From gitlab-com/www-gitlab-com#7048 (comment 340477667):
This article on martinfowler.com outlines 4 different categories of feature flags/toggles.
- Release Toggle - Short lived, used to enable unfinished code to be deployed
- Ops Toggle - Longer lived, used to disable features that have a performance impact
- Experiment Toggle - Longer lived, used to experiment (A/B test for example)
- Permission Toggle - Longer lived, used like a config to enable certain features for certain users
My personal feeling/opinion is that we should have one mechanism/tool to enable Release toggles and at least one separate mechanism/tool for the other three types. Reason being: the more different use-cases we have for a single tool, the more confusing it will be for engineers and other roles (PM, Design, Test Engineers, Infra, etc.) to use that tool in practice (Assuming engineers in general will use primarily Release toggles, and the other roles in general will primarily use the other three types). We can use having a separate tool as a clean delineation for deciding how to use feature flags.
That could look like:
- Using flipper or another feature flag mechanism without a UI for "release toggle/flag" work, targeted at engineers
- Using Unleash or another feature flag mechanism (Separate from the above) with a UI for non-"release toggle" work, targeted at other users (PM, Design, etc) who will primarily use Ops/Experiment/Permission flags
Permissions and Security
Documentation
Availability & Testing
What does success look like, and how can we measure that?
What is the type of buyer?
Is this a cross-stage feature?
Links / references
https://unleash.github.io/docs/feature_toggle_types
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.