Feature flags product discovery
Prior to tackling #779 we would like to evaluate server/client implementations of the solutions being considered. The goal of this issue is to
- Select which solution suits GitLab best from a scalability/maintainability/security perspective.
- Discuss and create a design artifact for #779.
Links / references
Unleash - open-source (apache 2.0), written in node.js, 19 contributors (no ruby client) https://github.com/Unleash/unleash
LaunchDarkly - not open-source, open-source clients (apache 2.0) https://github.com/launchdarkly
Split.io - not open-source, open-source clients (apache lic) https://github.com/splitio
We considered the following approaches:
- Adding a feature flag label to an issue to indicate the existence/strategy of a feature flag. This would negate the need for a dedicated frontend piece to manage and operate feature flags.
We concluded that the experience for both operators and developers is sub-optimal; for developers, viewing what's being toggled with an issue may not suffice. For operators, there is no central place to manage and operate feature flags.
- A dedicated place to manage and operate feature flags.
We concluded this provide us with more latitude to provide an intuitive way for both developers to place and track feature flags as well as provide operators a central place to manage and use feature flags.
Kamil put a great summary of existing solutions here: #779 (comment 83190393)
Corresponding delivery issue #779 (comment 83190393)
Mockups for MV:
This would allow us to expand feature flags by adding different strategies per flag. We can also extend environments by including different rule sets per flag. Rule sets could include:
- Status (enabled/disabled)
- Environment scope
- Segmented groups
- Percentage rollouts
The table would need to change as we add more features/the ability to add multiple rule sets per feature flag.
If we need to reduce scope for the first iteration, we can remove the percentage roll out as well as the tabs.