Commit adb115e9 authored by Zeger-Jan van de Weg's avatar Zeger-Jan van de Weg
Browse files

Document ChatOps for actor feature gates

The documentations only covered the percentage based feature gates.
These don't work really well for a number of reasons, for example; a new
visual element in GitLab would be weird to see only 25% of the time.

Allowing feature gates based on projects and groups has been supported,
now it's documented.
parent df0d3f9c
......@@ -135,6 +135,20 @@ want to wait several hours or even days. This is entirely up to you, just make
sure it is clearly communicated to your team, and the Production team if you
anticipate any potential problems.
Feature gates can also be actor based, for example a feature could first be
enabled for only the `gitlab-ce` project. The project is passed by supplying a
`--project` flag:
/chatops run feature set --project=gitlab-org/gitlab-ce some_feature true
For groups the `--group` flag is available:
/chatops run feature set --group=gitlab-org some_feature true
Once a change is deemed stable, submit a new merge request to remove the
feature flag. This ensures the change is available to all users and self-hosted
instances. Make sure to add the ~"feature flag" label to this merge request so
......@@ -188,3 +202,12 @@ to be shipped. You can do this via ChatOps:
Note that you can do this at any time, even before the merge request using the
flag has been merged!
### Cleaning up
When a feature gate has been removed from the code base, the value still exists
in the database. This can be removed through ChatOps:
/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