summaryrefslogtreecommitdiff
path: root/doc/development/feature_flags/controls.md
diff options
context:
space:
mode:
Diffstat (limited to 'doc/development/feature_flags/controls.md')
-rw-r--r--doc/development/feature_flags/controls.md18
1 files changed, 10 insertions, 8 deletions
diff --git a/doc/development/feature_flags/controls.md b/doc/development/feature_flags/controls.md
index 21ac152c469..fc327a2defc 100644
--- a/doc/development/feature_flags/controls.md
+++ b/doc/development/feature_flags/controls.md
@@ -36,7 +36,7 @@ easier to measure the impact of both separately.
The GitLab feature library (using
[Flipper](https://github.com/jnunemaker/flipper), and covered in the [Feature
-Flags process](process.md) guide) supports rolling out changes to a percentage of
+Flags process](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle) guide) supports rolling out changes to a percentage of
time to users. This in turn can be controlled using [GitLab ChatOps](../../ci/chatops/index.md).
For an up to date list of feature flag commands please see [the source
@@ -240,7 +240,7 @@ To disable a feature flag that has been enabled for a specific project you can r
/chatops run feature set --group=gitlab-org some_feature false
```
-You cannot selectively disable feature flags for a specific project/group/user without applying a [specific method of implementing](development.md#selectively-disable-by-actor) the feature flags.
+You cannot selectively disable feature flags for a specific project/group/user without applying a [specific method of implementing](index.md#selectively-disable-by-actor) the feature flags.
### Feature flag change logging
@@ -276,17 +276,19 @@ and reduces confidence in our testing suite covering all possible combinations.
Additionally, a feature flag overwritten in some of the environments can result
in undefined and untested system behavior.
-To remove a feature flag:
+To remove a feature flag, open **one merge request** to make the changes. In the MR:
-1. Open a new merge request with the ~"feature flag" label so
- release managers are aware the changes are hidden behind a feature flag.
+1. Add the ~"feature flag" label so release managers are aware the changes are hidden behind a feature flag.
1. If the merge request has to be picked into a stable branch, add the
appropriate `~"Pick into X.Y"` label, for example `~"Pick into 13.0"`.
- See [the feature flag process](process.md#including-a-feature-behind-feature-flag-in-the-final-release)
+ See [the feature flag process](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle#including-a-feature-behind-feature-flag-in-the-final-release)
for further details.
-1. Remove all references to the feature flag from the codebase.
+1. Remove all references to the feature flag from the codebase, including tests.
1. Remove the YAML definition for the feature from the repository.
-1. Clean up the feature flag from all environments with `/chatops run feature delete some_feature`.
+
+Once the above MR has been merged, you should:
+
+1. [Clean up the feature flag from all environments](#cleanup-chatops) with `/chatops run feature delete some_feature`.
1. Close the rollout issue for the feature flag after the feature flag is removed from the codebase.
### Cleanup ChatOps