Add feature flag guidelines to Fleet's public handbook (#2823)

- Add outline for when a feature is placed behind a feature flag in the Fleet product
- Add items to consider when deciding if feature flags should be leveraged
This commit is contained in:
Noah Talerman 2021-11-08 10:15:56 -05:00 committed by GitHub
parent 7db6de7278
commit bb600c030b
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -20,6 +20,17 @@ Below is a table of [directly responsible individuals (DRIs)](./people.md#direct
| Release notes | Noah Talerman |
| Publishing release blog post, and promoting releases | Mike Thomas |
## Feature flags
In Fleet, features are placed behind feature flags if the changes could affect Fleet's availability of existing functionalities.
The following highlights should be considered when deciding if feature flags should be leveraged:
- The feature flag must be disabled by default.
- The feature flag will not be permanent. This means that the individual who decides that a feature flag should be introduced is responsible for creating an issue to track the feature's progress towards removing the feature flag and including the feature in a stable release.
- The feature flag will not be advertised. For example, advertising in the documentation on fleetdm.com/docs, release notes, release blog posts, and Twitter.
Fleet's feature flag guidelines borrows from GitLab's ["When to use feature flags" section](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags) of their handbook. Check out [GitLab's "Feature flags only when needed" video](https://www.youtube.com/watch?v=DQaGqyolOd8) for an explanation on the costs of introducing feature flags.
## Fleet docs
### Adding a link to the Fleet docs