Rollout New Feature Flags
Rollout New Feature Flags
Phase 1: Rollout to Internal GitLab Customers
-
Enable new flags for https://gitlab.com/gitlab-services/version-gitlab-com/ (groupexpansion and ~"group::telemetry") -
Enable new flags for https://gitlab.com/gitlab-org/customers-gitlab-com/ (~"group::fulfillment")
Rollback strategy
If we disable the feature to rollback, users may have created new version flags while the feature was enabled.
In this scenario, new version feature flags that were created while the feature was enabled continue to be returned to Unleash clients, but otherwise behave as if they do not exist.
Details
Unleash clients continue to receive existing new version flags that were created while the new version flags were enabled. This is so that switching off the new features does not cause client code consuming the Unleash feature flags to change behavior.
For the UI:
- The UI will no longer get new version feature flags on the index page
- The view / edit a feature flag page will behave as if the new version flag does not exist (returning a 404, not found)
- New version flags can no longer be created
- Or deleted
- Or updated
For the Public CRUD API (/api/v4/feature_flags):
- GET requests for a list no longer return existing new version flags. They will still return legacy flags, filtering out the new version flags.
- GET requests for a single new version flag will return a 404 not found
- POST requests to create a new version flag will return a 422 and not create the flag
- PUT requests will return a 404 not found
- DELETE requests will return a 404 not found
Phase 2: Rollout to GitLab.com
-
Enable new flags for all of GitLab.com (Done in %13.1)
Phase 3: Rollout to Self-Managed
-
Default feature flag to enabled (Done in %13.2 with !35192 (merged))
Phase 4: Clean up
Remove feature flag. To be done in #258831 (closed).
Notes
New version flags are turned off and on via the :feature_flags_new_version feature flag.
Edited by Jason Goodman