kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Document ChatOps for actor feature gates

Browse source 
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.
This commit is contained in:
Zeger-Jan van de Weg 2019-03-06 16:11:54 +01:00
parent df0d3f9c67
commit adb115e9ed
1 changed files with 23 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

23
doc/development/rolling_out_changes_using_feature_flags.md
View file

@ -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
```