Skip to content
Snippets Groups Projects

Propose and document a location for running chatops commands

Merged Allison Browne requested to merge 32133-document-where-to-remove-feature-flags into master
All threads resolved!
# 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
have access to the chatops bot. Chatops bot is currently running on the ops instance,
which is different from GitLab.com or dev.gitlab.org.
have access to the [chatops](../chatops_on_gitlabcom.md) bot. The chatops bot
is currently running on the ops instance, which is different from GitLab.com
or dev.gitlab.org.
Follow the Chatops document to [request access](../chatops_on_gitlabcom.md#requesting-access).
@@ -14,6 +17,19 @@ run:
/chatops run feature --help
```
## Where to run commands
It is recommended that gitlab employees run feature flag related chatops commands
within certain slack channels based on the environment and product
the feature is related to. 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 that are part of the Monitor stage
and Health group milestones.
For all production environment chatops commands, use the `#production` channel.
## Rolling out changes
When the changes are deployed to the environments it is time to start
@@ -37,9 +53,9 @@ 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
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 staging and dev.gitlab.org
### Enabling feature for [staging](https://staging.gitlab.com) and [dev](https://dev.gitlab.org)
As a first step in a feature rollout, you should enable the feature on <https://staging.gitlab.com>
and <https://dev.gitlab.org>.
@@ -64,7 +80,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
feature enabled, you can roll out the change to GitLab.com.
## Enabling feature for GitLab.com
### Enabling feature for GitLab.com
Similar to above, to enable a feature for 25% of all users, run the following in
Slack:
@@ -114,9 +130,20 @@ 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").
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
in the database.
This can be removed through ChatOps:
When a feature gate has been removed from the code base, the feature
record still exists in the databases that the flag was deployed too. The record can be
removed on a per-environment basis after the relevant feature flag removal
MR is deployed.
Using chatops run a targeted staging and development delete first after the
MR has been deployed to these environments:
```
/chatops run feature delete some_feature --dev
/chatops run feature delete some_feature --staging
```
then run a production delete after the MR is deployed to prod:
```
/chatops run feature delete some_feature
Loading