diff options
Diffstat (limited to 'doc/development/feature_flags/controls.md')
| -rw-r--r-- | doc/development/feature_flags/controls.md | 20 |
1 files changed, 14 insertions, 6 deletions
diff --git a/doc/development/feature_flags/controls.md b/doc/development/feature_flags/controls.md index df737912c00..7551199aa58 100644 --- a/doc/development/feature_flags/controls.md +++ b/doc/development/feature_flags/controls.md @@ -34,7 +34,7 @@ _before_ the code is being deployed. This allows you to separate rolling out a feature from a deploy, making it easier to measure the impact of both separately. -GitLab's feature library (using +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 time to users. This in turn can be controlled using [GitLab Chatops](../../ci/chatops/README.md). @@ -50,7 +50,7 @@ change feature flags or you do not [have access](#access). ### Enabling a feature for preproduction testing -As a first step in a feature rollout, you should enable the feature on <https://staging.gitlab.com> +As a first step in a feature rollout, you should enable the feature on <https://about.staging.gitlab.com> and <https://dev.gitlab.org>. These two environments have different scopes. @@ -228,21 +228,29 @@ existing gates (e.g. `--group=gitlab-org`) in the above processes. ### Feature flag change logging -Any feature flag change that affects GitLab.com (production) will -automatically be logged in an issue. +#### Chatops level + +Any feature flag change that affects GitLab.com (production) via [Chatops](https://gitlab.com/gitlab-com/chatops) +is automatically logged in an issue. The issue is created in the [gl-infra/feature-flag-log](https://gitlab.com/gitlab-com/gl-infra/feature-flag-log/-/issues?scope=all&utf8=%E2%9C%93&state=closed) project, and it will at minimum log the Slack handle of person enabling a feature flag, the time, and the name of the flag being changed. -The issue is then also posted to GitLab's internal +The issue is then also posted to the GitLab internal [Grafana dashboard](https://dashboards.gitlab.net/) as an annotation marker to make the change even more visible. Changes to the issue format can be submitted in the [Chatops project](https://gitlab.com/gitlab-com/chatops). +#### Instance level + +Any feature flag change that affects any GitLab instance is automatically logged in +[features_json.log](../../administration/logs.md#features_jsonlog). +You can search the change history in [Kibana](https://about.gitlab.com/handbook/support/workflows/kibana.html). + ## Cleaning up A feature flag should be removed as soon as it is no longer needed. Each additional @@ -266,7 +274,7 @@ To remove a feature flag: ### Cleanup ChatOps -When a feature gate has been removed from the code base, the feature +When a feature gate has been removed from the codebase, the feature record still exists in the database that the flag was deployed too. The record can be deleted once the MR is deployed to each environment: |