diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-05-20 14:34:42 +0000 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-05-20 14:34:42 +0000 |
commit | 9f46488805e86b1bc341ea1620b866016c2ce5ed (patch) | |
tree | f9748c7e287041e37d6da49e0a29c9511dc34768 /doc/development/documentation/feature_flags.md | |
parent | dfc92d081ea0332d69c8aca2f0e745cb48ae5e6d (diff) | |
download | gitlab-ce-9f46488805e86b1bc341ea1620b866016c2ce5ed.tar.gz |
Add latest changes from gitlab-org/gitlab@13-0-stable-ee
Diffstat (limited to 'doc/development/documentation/feature_flags.md')
-rw-r--r-- | doc/development/documentation/feature_flags.md | 188 |
1 files changed, 188 insertions, 0 deletions
diff --git a/doc/development/documentation/feature_flags.md b/doc/development/documentation/feature_flags.md new file mode 100644 index 00000000000..373c5a4ee7d --- /dev/null +++ b/doc/development/documentation/feature_flags.md @@ -0,0 +1,188 @@ +--- +type: reference +description: "GitLab development - how to document features deployed behind feature flags" +--- + +# Document features deployed behind feature flags + +GitLab uses [Feature Flags](../feature_flags/index.md) to strategically roll +out the deployment of its own features. The way we document a feature behind a +feature flag depends on its state (enabled or disabled). When the state +changes, the developer who made the change **must update the documentation** +accordingly. + +## Criteria + +According to the process of [deploying GitLab features behind feature flags](../feature_flags/process.md): + +> - _By default, feature flags should be off._ +> - _Feature flags should remain in the codebase for a short period as possible to reduce the need for feature flag accounting._ +> - _In order to build a final release and present the feature for self-managed users, the feature flag should be at least defaulted to on._ + +See how to document them below, according to the state of the flag: + +- [Features disabled by default](#features-disabled-by-default). +- [Features that became enabled by default](#features-that-became-enabled-by-default). +- [Features directly enabled by default](#features-directly-enabled-by-default). +- [Features with the feature flag removed](#features-with-flag-removed). + +NOTE: **Note:** +The [`**(CORE ONLY)**`](styleguide.md#product-badges) badge or equivalent for +the feature's tier should be added to the line and heading that refers to +enabling/disabling feature flags as Admin access is required to do so, +therefore, it indicates that it cannot be done by regular users of GitLab.com. + +### Features disabled by default + +For features disabled by default, if they cannot be used yet due to lack of +completeness, or if they're still under internal evaluation (for example, for +performance implications) do **not document them**: add (or merge) the docs +only when the feature is safe and ready to use and test by end users. + +For feature flags disabled by default, if they can be used by end users: + +- Say that it's disabled by default. +- Say whether it's enabled on GitLab.com. +- Say whether it's recommended for production use. +- Document how to enable and disable it. + +For example, for a feature disabled by default, disabled on GitLab.com, and +not ready for production use: + +````markdown +# Feature Name + +> - [Introduced](link-to-issue) in GitLab 12.0. +> - It's deployed behind a feature flag, disabled by default. +> - It's disabled on GitLab.com. +> - It's not recommended for production use. +> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#anchor-to-section). **(CORE ONLY)** + +(...) + +### Enable or disable <Feature Name> **(CORE ONLY)** + +<Feature Name> is under development and not ready for production use. It is +deployed behind a feature flag that is **disabled by default**. +[GitLab administrators with access to the GitLab Rails console](../path/to/administration/feature_flags.md) +can enable it for your instance. + +To enable it: + +```ruby +Feature.enable(:<feature flag>) +``` + +To disable it: + +```ruby +Feature.disable(:<feature flag>) +``` +```` + +Adjust the blurb according to the state of the feature you're documenting. + +### Features that became enabled by default + +For features that became enabled by default: + +- Say that it became enabled by default. +- Say whether it's enabled on GitLab.com. +- Say whether it's recommended for production use. +- Document how to disable and enable it. + +For example, for a feature initially deployed disabled by default, that became enabled by default, that is enabled on GitLab.com, and ready for production use: + +````markdown +# Feature Name + +> - [Introduced](link-to-issue) in GitLab 12.0. +> - It was deployed behind a feature flag, disabled by default. +> - [Became enabled by default](link-to-issue) on GitLab 12.1. +> - It's enabled on GitLab.com. +> - It's recommended for production use. +> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#anchor-to-section). **(CORE ONLY)** + +(...) + +### Enable or disable <Feature Name> **(CORE ONLY)** + +<Feature Name> is under development but ready for production use. +It is deployed behind a feature flag that is **enabled by default**. +[GitLab administrators with access to the GitLab Rails console](..path/to/administration/feature_flags.md) +can opt to disable it for your instance. + +To disable it: + +```ruby +Feature.disable(:<feature flag>) +``` + +To enable it: + +```ruby +Feature.enable(:<feature flag>) +``` +```` + +Adjust the blurb according to the state of the feature you're documenting. + +### Features directly enabled by default + +For features enabled by default: + +- Say it's enabled by default. +- Say whether it's enabled on GitLab.com. +- Say whether it's recommended for production use. +- Document how to disable and enable it. + +For example, for a feature enabled by default, enabled on GitLab.com, and ready for production use: + +````markdown +# Feature Name + +> - [Introduced](link-to-issue) in GitLab 12.0. +> - It's deployed behind a feature flag, enabled by default. +> - It's enabled on GitLab.com. +> - It's recommended for production use. +> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#anchor-to-section). **(CORE ONLY)** + +(...) + +### Enable or disable <Feature Name> **(CORE ONLY)** + +<Feature Name> is under development but ready for production use. +It is deployed behind a feature flag that is **enabled by default**. +[GitLab administrators with access to the GitLab Rails console](..path/to/administration/feature_flags.md) +can opt to disable it for your instance. + +To disable it: + +```ruby +Feature.disable(:<feature flag>) +``` + +To enable it: + +```ruby +Feature.enable(:<feature flag>) +``` +```` + +Adjust the blurb according to the state of the feature you're documenting. + +### Features with flag removed + +Once the feature is ready and the flag has been removed, clean up the +documentation. Remove the feature flag mention keeping only a note that +mentions the flag in the version history notes: + +````markdown +# Feature Name + +> - [Introduced](link-to-issue) in GitLab 12.0. +> - [Feature flag removed](link-to-issue) in GitLab 12.2. + +(...) + +```` |