Commit a90851c2 authored by Achilleas Pipinellis's avatar Achilleas Pipinellis

Merge branch '32133-document-where-to-remove-feature-flags' into 'master'

Propose and document a location for running chatops commands

See merge request gitlab-org/gitlab!18229
parents 5a18c42d 45a5e320
# Access for enabling a feature flag in production # Feature flag controls
In order to be able to turn on/off features behind feature flags in any of the ## Access
To be able to turn on/off features behind feature flags in any of the
GitLab Inc. provided environments such as staging and production, you need to GitLab Inc. provided environments such as staging and production, you need to
have access to the chatops bot. Chatops bot is currently running on the ops instance, have access to the [Chatops](../chatops_on_gitlabcom.md) bot. The Chatops bot
which is different from <https://gitlab.com> or <https://dev.gitlab.org>. is currently running on the ops instance, which is different from <https://gitlab.com> or <https://dev.gitlab.org>.
Follow the Chatops document to [request access](../chatops_on_gitlabcom.md#requesting-access). Follow the Chatops document to [request access](../chatops_on_gitlabcom.md#requesting-access).
...@@ -14,6 +16,19 @@ run: ...@@ -14,6 +16,19 @@ run:
/chatops run feature --help /chatops run feature --help
``` ```
## Where to run commands
To increase visibility, we recommend that GitLab team members run feature flag
related Chatops commands within certain slack channels based on the environment
and related feature. For the [staging](https://staging.gitlab.com)
and [development](https://dev.gitlab.org) environments of GitLab.com,
the commands should run in a channel for the stage the feature is relevant too.
For example, use the `#s_monitor` channel for features developed by the
Monitor stage, Health group.
For all production environment Chatops commands, use the `#production` channel.
## Rolling out changes ## Rolling out changes
When the changes are deployed to the environments it is time to start When the changes are deployed to the environments it is time to start
...@@ -28,7 +43,7 @@ easier to measure the impact of both separately. ...@@ -28,7 +43,7 @@ easier to measure the impact of both separately.
GitLab's feature library (using GitLab's feature library (using
[Flipper](https://github.com/jnunemaker/flipper), and covered in the [Feature [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](process.md) guide) supports rolling out changes to a percentage of
users. This in turn can be controlled using [GitLab chatops](../../ci/chatops/README.md). users. This in turn can be controlled using [GitLab Chatops](../../ci/chatops/README.md).
For an up to date list of feature flag commands please see [the source For an up to date list of feature flag commands please see [the source
code](https://gitlab.com/gitlab-com/chatops/blob/master/lib/chatops/commands/feature.rb). code](https://gitlab.com/gitlab-com/chatops/blob/master/lib/chatops/commands/feature.rb).
...@@ -37,7 +52,7 @@ Note that all the examples in that file must be preceded by ...@@ -37,7 +52,7 @@ Note that all the examples in that file must be preceded by
If you get an error "Whoops! This action is not allowed. This incident If you get an error "Whoops! This action is not allowed. This incident
will be reported." that means your Slack account is not allowed to will be reported." that means your Slack account is not allowed to
change feature flags or you do not [have access](#access-for-enabling-a-feature-flag-in-production). change feature flags or you do not [have access](#access).
### Enabling feature for internal testing ### Enabling feature for internal testing
...@@ -64,7 +79,7 @@ there for any exceptions while testing your feature after enabling the feature f ...@@ -64,7 +79,7 @@ there for any exceptions while testing your feature after enabling the feature f
Once you are confident enough that these environments are in a good state with your Once you are confident enough that these environments are in a good state with your
feature enabled, you can roll out the change to GitLab.com. feature enabled, you can roll out the change to GitLab.com.
## Enabling feature for GitLab.com ### Enabling a feature for GitLab.com
Similar to above, to enable a feature for 25% of all users, run the following in Similar to above, to enable a feature for 25% of all users, run the following in
Slack: Slack:
...@@ -114,10 +129,17 @@ merge request has to be picked into a stable branch, make sure to also add the ...@@ -114,10 +129,17 @@ merge request has to be picked into a stable branch, make sure to also add the
appropriate "Pick into X" label (e.g. "Pick into XX.X"). appropriate "Pick into X" label (e.g. "Pick into XX.X").
See [the process document](process.md#including-a-feature-behind-feature-flag-in-the-final-release) for further details. See [the process document](process.md#including-a-feature-behind-feature-flag-in-the-final-release) for further details.
When a feature gate has been removed from the code base, the value still exists When a feature gate has been removed from the code base, the feature
in the database. record still exists in the database that the flag was deployed too.
This can be removed through ChatOps: The record can be deleted once the MR is deployed to each environment:
```sh
/chatops run feature delete some_feature --dev
/chatops run feature delete some_feature --staging
``` ```
Then, you can delete it from production after the MR is deployed to prod:
```sh
/chatops run feature delete some_feature /chatops run feature delete some_feature
``` ```
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment