Feature flags product discovery

Description

Prior to tackling https://gitlab.com/gitlab-org/gitlab-ee/issues/779 we would like to evaluate server/client implementations of the solutions being considered. The goal of this issue is to

  1. Select which solution suits GitLab best from a scalability/maintainability/security perspective.
  2. Discuss and create a ~"design artifact" for https://gitlab.com/gitlab-org/gitlab-ee/issues/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

Findings

We considered the following approaches:

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

image

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.

  1. A dedicated place to manage and operate feature flags.

image

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.

Next Steps

For MVC we will implement a GitLab backend and use Unleash client libraries. We will iterate from there.

Kamil put a great summary of existing solutions here: https://gitlab.com/gitlab-org/gitlab-ee/issues/779#note_83190393

Corresponding delivery issue https://gitlab.com/gitlab-org/gitlab-ee/issues/779#note_83190393

Design

Mockups for MV:

feature-flag__list feature-flag__list--configure feature-flag__new

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.

Edited by Taurie Davis