Ability to set feature flag on/off status per-environment
Problem to solve
As of the initial launch of feature flags, it's only possible to turn a feature flag on/off everywhere at once.
It is normal in a feature flag workflow to have different states on a per-environment basis; production may have a feature off still, for example, but it may be on in a staging environment. You may have a matrix like the following, for example:
environment | status |
---|---|
production | off |
stage | off |
qa | on |
review/* | on |
other (default) | on |
You'd want the ability to control those toggles individually, rather than just having one button that turns it on and off everywhere as it is now.
Use Cases
There are two main contexts where you'll be changing feature flags:
- Feature Flag view: Where you're looking at one feature flag, and want to toggle that feature flag on or off in various environments. That is covered by this issue.
- Environment view: Where you're looking at one environment, and want to toggle various feature flags on or off. That is covered by https://gitlab.com/gitlab-org/gitlab-ee/issues/9098 and considered out of scope for this one, but is referenced here as an important context to consider.
Solution
It will be possible, for all environments, to be able to individually set the on/off status for a feature flag. Feature flag behavior is built up by creating a set of rules based on environment specs. There is always a default wildcard rule (*
), but you are able to add more rules by adding more environment specs (for example, review/*
, and you can add as many as you need. The most specific rule that matches in the list is used. Each environment spec/the default has an ON/OFF value which indicates the behavior if that is the most specific match for the environment in question.
Adding and removing rules should work similarly to the table where you add secret variables to a project; you can add a row at a time, and each time you add a row, a new blank one at the bottom is prepared for you.
A note on terminology: A feature flag can be active
or inactive
. A feature flag is enabled on at least one environment. An environment spec rule can be set which results in the API returning on
or off
for that environment via the API. If all rules are set to return off
, then a feature flag is inactive
; otherwise it is active
.
Mockups
Feature Flag overview
Feature Flag overview | Mobile |
---|---|
Create New/Edit Feature Flag
Form | Mobile |
---|---|
User journey
- User sees a tabular list of existing Feature Flags on the overview page.
- Additionally, the table should display a new column with the environments the Feature Flag is active on. The environments are displayed in labels. Hovering the label should display a tooltip.
- The tags are displayed in a similar order as they are set by the user in the create form
- User clicks the button to Create or Edit a Feature Flag, he/she is taken to a detail view. The detail view page shows the already implemented form, and additionally it should include a table view with:
- Section header and helper text.
- A dropdown select component, with the ability to see/select/filter existing environments.
- A toggle component, displayed on a 'Status' column. Toggling it 'on' should activate the flag for the environment. Toggling it 'off' should inactivate it.
- The default scope's (
*
) spec is not editable but users can toggle it on/off
- Changes will be applied once the user hits the 'Save' button. User should then be redirected to the overview page, just as current implemented flow.
Additional task
- Remove the checkbox option in the original form to set the environment status.
- Update the tab navigation labels to match correct statuses naming
What does success look like, and how can we measure that?
- User should be able to set the status of a Feature Flag per environment via Feature Flags page.
TODO:
Backend
-
Support Ajax endpoints for FeatureFlagsController https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9127 -
Multiple environments support for feature flags (Unleash API standpoint) https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9110 -
Support CURD operation for feature flag scopes (GitLab internal API standpoint) https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9182 -
BE small fix => https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9357
Frontend
-
Move the rest of the index page into Vue - https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9155 -
Add column in the index page - https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9196 -
Move new/edit pages into vue - https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9228 -
Add environments to new/edit pages - https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9228
Others
-
Remove "Application name: production" from the modal - https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9262 -
Feature specs => https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9357 -
Documents => https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9385
Links / references
- https://gitlab.com/gitlab-org/gitlab-ce/issues/56310 later adds sorting for the list of environment scopes