Commit 015bca05 authored by Marcia Ramos's avatar Marcia Ramos

Merge branch 'rw/move-ff-docs-to-handbook' into 'master'

Moving process docs for feature flags to handbook

See merge request gitlab-org/gitlab!55891
parents fa36774e 99b8f8c3
...@@ -9,10 +9,10 @@ The changes need to become an official part of the product. ...@@ -9,10 +9,10 @@ The changes need to become an official part of the product.
- [ ] Determine whether the feature should apply to SaaS and/or self-managed - [ ] Determine whether the feature should apply to SaaS and/or self-managed
- [ ] Determine whether the feature should apply to EE - and which tiers - and/or Core - [ ] Determine whether the feature should apply to EE - and which tiers - and/or Core
- [ ] Determine if tracking should be kept as is, removed, or modified - [ ] Determine if tracking should be kept as is, removed, or modified.
- [ ] Ensure any relevant documentation has been updated. - [ ] Ensure any relevant documentation has been updated.
- [ ] Consider changes to any `feature_category:` introduced by the experiment if ownership is changing (PM for Growth and PM for the new category as DRIs) - [ ] Consider changes to any `feature_category:` introduced by the experiment if ownership is changing (PM for Growth and PM for the new category as DRIs)
- [ ] Optional: Migrate experiment to a default enabled [feature flag](https://docs.gitlab.com/ee/development/feature_flags/development.html) for one milestone and add a changelog. Converting to a feature flag can be skipped at the ICs discretion if risk is deemed low with consideration to both SaaS and (if applicable) self managed - [ ] Optional: Migrate experiment to a default enabled [feature flag](https://docs.gitlab.com/ee/development/feature_flags) for one milestone and add a changelog. Converting to a feature flag can be skipped at the ICs discretion if risk is deemed low with consideration to both SaaS and (if applicable) self managed
- [ ] In the next milestone, [remove the feature flag](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up) if applicable - [ ] In the next milestone, [remove the feature flag](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up) if applicable
- [ ] After the flag removal is deployed, [clean up the feature/experiment feature flags](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up) by running chatops command in `#production` channel - [ ] After the flag removal is deployed, [clean up the feature/experiment feature flags](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up) by running chatops command in `#production` channel
......
...@@ -77,9 +77,9 @@ star, smile, etc.). Some good tips about code reviews can be found in our ...@@ -77,9 +77,9 @@ star, smile, etc.). Some good tips about code reviews can be found in our
## Feature flags ## Feature flags
Overview and details of feature flag processes in development of GitLab itself is described in [feature flags process documentation](https://docs.gitlab.com/ee/development/feature_flags/process.html). Overview and details of feature flag processes in development of GitLab itself is described in [feature flags process documentation](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/).
Guides on how to include feature flags in your backend/frontend code while developing GitLab are described in [developing with feature flags documentation](https://docs.gitlab.com/ee/development/feature_flags/development.html). Guides on how to include feature flags in your backend/frontend code while developing GitLab are described in [developing with feature flags documentation](https://docs.gitlab.com/ee/development/feature_flags).
Getting access and how to expose the feature to users is detailed in [controlling feature flags documentation](https://docs.gitlab.com/ee/development/feature_flags/controls.html). Getting access and how to expose the feature to users is detailed in [controlling feature flags documentation](https://docs.gitlab.com/ee/development/feature_flags/controls.html).
......
# frozen_string_literal: true # frozen_string_literal: true
# rubocop:disable Style/SignalException # rubocop:disable Style/SignalException
SEE_DOC = "See the [feature flag documentation](https://docs.gitlab.com/ee/development/feature_flags/development.html#feature-flag-definition-and-validation)." SEE_DOC = "See the [feature flag documentation](https://docs.gitlab.com/ee/development/feature_flags#feature-flag-definition-and-validation)."
SUGGEST_MR_COMMENT = <<~SUGGEST_COMMENT SUGGEST_MR_COMMENT = <<~SUGGEST_COMMENT
```suggestion ```suggestion
......
...@@ -13,7 +13,7 @@ to deploy features in an early stage of development so that they can be ...@@ -13,7 +13,7 @@ to deploy features in an early stage of development so that they can be
incrementally rolled out. incrementally rolled out.
Before making them permanently available, features can be deployed behind Before making them permanently available, features can be deployed behind
flags for a [number of reasons](../development/feature_flags/index.md#when-to-use-feature-flags), such as: flags for a [number of reasons](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle#when-to-use-feature-flags), such as:
- To test the feature. - To test the feature.
- To get feedback from users and customers while in an early stage of the development of the feature. - To get feedback from users and customers while in an early stage of the development of the feature.
......
...@@ -470,7 +470,7 @@ fails. Consider this when toggling the visibility of the feature on or off on ...@@ -470,7 +470,7 @@ fails. Consider this when toggling the visibility of the feature on or off on
production. production.
The `feature_flag` property does not allow the use of The `feature_flag` property does not allow the use of
[feature gates based on actors](../development/feature_flags/development.md). [feature gates based on actors](../development/feature_flags/index.md).
This means that the feature flag cannot be toggled only for particular This means that the feature flag cannot be toggled only for particular
projects, groups, or users, but instead can only be toggled globally for projects, groups, or users, but instead can only be toggled globally for
everyone. everyone.
......
...@@ -57,7 +57,7 @@ the `author` field. GitLab team members **should not**. ...@@ -57,7 +57,7 @@ the `author` field. GitLab team members **should not**.
- Any change behind an enabled feature flag **should** have a changelog entry. - Any change behind an enabled feature flag **should** have a changelog entry.
- Any change that adds new usage data metrics and changes that needs to be documented in Product Intelligence [Event Dictionary](https://about.gitlab.com/handbook/product/product-intelligence-guide/#event-dictionary) **should** have a changelog entry. - Any change that adds new usage data metrics and changes that needs to be documented in Product Intelligence [Event Dictionary](https://about.gitlab.com/handbook/product/product-intelligence-guide/#event-dictionary) **should** have a changelog entry.
- A change that adds snowplow events **should** have a changelog entry - - A change that adds snowplow events **should** have a changelog entry -
- A change that [removes a feature flag](feature_flags/development.md) **must** have a changelog entry. - A change that [removes a feature flag](feature_flags/index.md) **must** have a changelog entry.
- A fix for a regression introduced and then fixed in the same release (i.e., - A fix for a regression introduced and then fixed in the same release (i.e.,
fixing a bug introduced during a monthly release candidate) **should not** fixing a bug introduced during a monthly release candidate) **should not**
have a changelog entry. have a changelog entry.
......
...@@ -61,4 +61,4 @@ To request access to ChatOps on GitLab.com: ...@@ -61,4 +61,4 @@ To request access to ChatOps on GitLab.com:
- [ChatOps Usage](../ci/chatops/index.md) - [ChatOps Usage](../ci/chatops/index.md)
- [Understanding EXPLAIN plans](understanding_explain_plans.md) - [Understanding EXPLAIN plans](understanding_explain_plans.md)
- [Feature Groups](feature_flags/development.md#feature-groups) - [Feature Groups](feature_flags/index.md#feature-groups)
...@@ -20,7 +20,7 @@ must be documented. For context, see the ...@@ -20,7 +20,7 @@ must be documented. For context, see the
## Criteria ## Criteria
According to the process of [deploying GitLab features behind feature flags](../feature_flags/process.md): According to the process of [deploying GitLab features behind feature flags](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle):
> - _By default, feature flags should be off._ > - _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._ > - _Feature flags should remain in the codebase for a short period as possible to reduce the need for feature flag accounting._
......
...@@ -45,7 +45,7 @@ One is built into GitLab directly and has been around for a while (this is calle ...@@ -45,7 +45,7 @@ One is built into GitLab directly and has been around for a while (this is calle
[`gitlab-experiment`](https://gitlab.com/gitlab-org/gitlab-experiment) and is referred [`gitlab-experiment`](https://gitlab.com/gitlab-org/gitlab-experiment) and is referred
to as `Gitlab::Experiment` -- GLEX for short. to as `Gitlab::Experiment` -- GLEX for short.
Both approaches use [experiment](../feature_flags/development.md#experiment-type) Both approaches use [experiment](../feature_flags/index.md#experiment-type)
feature flags, and there is currently no strong suggestion to use one over the other. feature flags, and there is currently no strong suggestion to use one over the other.
| Feature | `Experimentation Module` | GLEX | | Feature | `Experimentation Module` | GLEX |
......
...@@ -423,7 +423,7 @@ query getAuthorData($authorNameEnabled: Boolean = false) { ...@@ -423,7 +423,7 @@ query getAuthorData($authorNameEnabled: Boolean = false) {
``` ```
Then in the Vue (or JavaScript) call to the query we can pass in our feature flag. This feature Then in the Vue (or JavaScript) call to the query we can pass in our feature flag. This feature
flag needs to be already set up correctly. See the [feature flag documentation](../feature_flags/development.md) flag needs to be already set up correctly. See the [feature flag documentation](../feature_flags/index.md)
for the correct way to do this. for the correct way to do this.
```javascript ```javascript
......
...@@ -36,7 +36,7 @@ easier to measure the impact of both separately. ...@@ -36,7 +36,7 @@ easier to measure the impact of both separately.
The GitLab feature library (using The GitLab feature library (using
[Flipper](https://github.com/jnunemaker/flipper), and covered in the [Feature [Flipper](https://github.com/jnunemaker/flipper), and covered in the [Feature
Flags process](process.md) guide) supports rolling out changes to a percentage of Flags process](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle) guide) supports rolling out changes to a percentage of
time to users. This in turn can be controlled using [GitLab ChatOps](../../ci/chatops/index.md). time to users. This in turn can be controlled using [GitLab ChatOps](../../ci/chatops/index.md).
For an up to date list of feature flag commands please see [the source For an up to date list of feature flag commands please see [the source
...@@ -240,7 +240,7 @@ To disable a feature flag that has been enabled for a specific project you can r ...@@ -240,7 +240,7 @@ To disable a feature flag that has been enabled for a specific project you can r
/chatops run feature set --group=gitlab-org some_feature false /chatops run feature set --group=gitlab-org some_feature false
``` ```
You cannot selectively disable feature flags for a specific project/group/user without applying a [specific method of implementing](development.md#selectively-disable-by-actor) the feature flags. You cannot selectively disable feature flags for a specific project/group/user without applying a [specific method of implementing](index.md#selectively-disable-by-actor) the feature flags.
### Feature flag change logging ### Feature flag change logging
...@@ -281,7 +281,7 @@ To remove a feature flag, open **one merge request** to make the changes. In the ...@@ -281,7 +281,7 @@ To remove a feature flag, open **one merge request** to make the changes. In the
1. Add the ~"feature flag" label so release managers are aware the changes are hidden behind a feature flag. 1. Add the ~"feature flag" label so release managers are aware the changes are hidden behind a feature flag.
1. If the merge request has to be picked into a stable branch, add the 1. If the merge request has to be picked into a stable branch, add the
appropriate `~"Pick into X.Y"` label, for example `~"Pick into 13.0"`. appropriate `~"Pick into X.Y"` label, for example `~"Pick into 13.0"`.
See [the feature flag process](process.md#including-a-feature-behind-feature-flag-in-the-final-release) See [the feature flag process](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle#including-a-feature-behind-feature-flag-in-the-final-release)
for further details. for further details.
1. Remove all references to the feature flag from the codebase, including tests. 1. Remove all references to the feature flag from the codebase, including tests.
1. Remove the YAML definition for the feature from the repository. 1. Remove the YAML definition for the feature from the repository.
......
This diff is collapsed.
This diff is collapsed.
...@@ -459,7 +459,7 @@ Performance deficiencies should be addressed right away after we merge initial ...@@ -459,7 +459,7 @@ Performance deficiencies should be addressed right away after we merge initial
changes. changes.
Read more about when and how feature flags should be used in Read more about when and how feature flags should be used in
[Feature flags in GitLab development](feature_flags/process.md#feature-flags-in-gitlab-development). [Feature flags in GitLab development](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle#feature-flags-in-gitlab-development).
## Storage ## Storage
......
...@@ -16,18 +16,18 @@ yarn clean ...@@ -16,18 +16,18 @@ yarn clean
## Creating feature flags in development ## Creating feature flags in development
The process for creating a feature flag is the same as [enabling a feature flag in development](../feature_flags/development.md#enabling-a-feature-flag-locally-in-development). The process for creating a feature flag is the same as [enabling a feature flag in development](../feature_flags/index.md#enabling-a-feature-flag-locally-in-development).
Your feature flag can now be: Your feature flag can now be:
- [Made available to the frontend](../feature_flags/development.md#frontend) via the `gon` - [Made available to the frontend](../feature_flags/index.md#frontend) via the `gon`
- Queried in [tests](../feature_flags/development.md#feature-flags-in-tests) - Queried in [tests](../feature_flags/index.md#feature-flags-in-tests)
- Queried in HAML templates and Ruby files via the `Feature.enabled?(:my_shiny_new_feature_flag)` method - Queried in HAML templates and Ruby files via the `Feature.enabled?(:my_shiny_new_feature_flag)` method
### More on feature flags ### More on feature flags
- [Deleting a feature flag](../../api/features.md#delete-a-feature) - [Deleting a feature flag](../../api/features.md#delete-a-feature)
- [Manage feature flags](../feature_flags/process.md) - [Manage feature flags](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle)
- [Feature flags API](../../api/features.md) - [Feature flags API](../../api/features.md)
## Running tests locally ## Running tests locally
......
...@@ -122,7 +122,7 @@ There are usually 2 phases for the MVC: ...@@ -122,7 +122,7 @@ There are usually 2 phases for the MVC:
When implementing a new package manager, it is tempting to create one large merge request containing all of the When implementing a new package manager, it is tempting to create one large merge request containing all of the
necessary endpoints and services necessary to support basic usage. Instead, put the necessary endpoints and services necessary to support basic usage. Instead, put the
API endpoints behind a [feature flag](feature_flags/development.md) and API endpoints behind a [feature flag](feature_flags/index.md) and
submit each endpoint or behavior (download, upload, etc) in a different merge request to shorten the review submit each endpoint or behavior (download, upload, etc) in a different merge request to shorten the review
process. process.
......
...@@ -75,7 +75,7 @@ To actually use it, you need to enable measuring for the desired service by enab ...@@ -75,7 +75,7 @@ To actually use it, you need to enable measuring for the desired service by enab
### Enabling measurement using feature flags ### Enabling measurement using feature flags
In the following example, the `:gitlab_service_measuring_projects_import_service` In the following example, the `:gitlab_service_measuring_projects_import_service`
[feature flag](feature_flags/development.md#enabling-a-feature-flag-locally-in-development) is used to enable the measuring feature [feature flag](feature_flags/index.md#enabling-a-feature-flag-locally-in-development) is used to enable the measuring feature
for `Projects::ImportService`. for `Projects::ImportService`.
From ChatOps: From ChatOps:
......
...@@ -545,7 +545,7 @@ end ...@@ -545,7 +545,7 @@ end
### Feature flags in tests ### Feature flags in tests
This section was moved to [developing with feature flags](../feature_flags/development.md). This section was moved to [developing with feature flags](../feature_flags/index.md).
### Pristine test environments ### Pristine test environments
......
...@@ -18,8 +18,8 @@ Please be sure to include the tag `:requires_admin` so that the test can be skip ...@@ -18,8 +18,8 @@ Please be sure to include the tag `:requires_admin` so that the test can be skip
where admin access is not available. where admin access is not available.
WARNING: WARNING:
You are strongly advised to [enable feature flags only for a group, project, user](../../feature_flags/development.md#feature-actors), You are strongly advised to [enable feature flags only for a group, project, user](../../feature_flags/index.md#feature-actors),
or [feature group](../../feature_flags/development.md#feature-groups). This makes it possible to or [feature group](../../feature_flags/index.md#feature-groups). This makes it possible to
test a feature in a shared environment without affecting other users. test a feature in a shared environment without affecting other users.
For example, the code below would enable a feature flag named `:feature_flag_name` for the project For example, the code below would enable a feature flag named `:feature_flag_name` for the project
......
...@@ -3,6 +3,5 @@ redirect_to: 'usage_ping/index.md' ...@@ -3,6 +3,5 @@ redirect_to: 'usage_ping/index.md'
--- ---
This document was moved to [another location](usage_ping/index.md). This document was moved to [another location](usage_ping/index.md).
<!-- This redirect file can be deleted after <2021-05-23>. --> <!-- This redirect file can be deleted after <2021-05-23>. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page --> <!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
\ No newline at end of file
...@@ -947,7 +947,7 @@ Each aggregate definition includes following parts: ...@@ -947,7 +947,7 @@ Each aggregate definition includes following parts:
relay on the same data source. Additional data source requirements are described in the relay on the same data source. Additional data source requirements are described in the
[Database sourced aggregated metrics](#database-sourced-aggregated-metrics) and [Database sourced aggregated metrics](#database-sourced-aggregated-metrics) and
[Redis sourced aggregated metrics](#redis-sourced-aggregated-metrics) sections. [Redis sourced aggregated metrics](#redis-sourced-aggregated-metrics) sections.
- `feature_flag`: Name of [development feature flag](../feature_flags/development.md#development-type) - `feature_flag`: Name of [development feature flag](../feature_flags/index.md#development-type)
that is checked before metrics aggregation is performed. Corresponding feature flag that is checked before metrics aggregation is performed. Corresponding feature flag
should have `default_enabled` attribute set to `false`. The `feature_flag` attribute should have `default_enabled` attribute set to `false`. The `feature_flag` attribute
is optional and can be omitted. When `feature_flag` is missing, no feature flag is checked. is optional and can be omitted. When `feature_flag` is missing, no feature flag is checked.
......
...@@ -61,6 +61,6 @@ The following analytics features are available at the project level: ...@@ -61,6 +61,6 @@ The following analytics features are available at the project level:
- [Insights](../project/insights/index.md). **(ULTIMATE)** - [Insights](../project/insights/index.md). **(ULTIMATE)**
- [Issue](../group/issues_analytics/index.md). **(PREMIUM)** - [Issue](../group/issues_analytics/index.md). **(PREMIUM)**
- [Merge Request](merge_request_analytics.md), enabled with the `project_merge_request_analytics` - [Merge Request](merge_request_analytics.md), enabled with the `project_merge_request_analytics`
[feature flag](../../development/feature_flags/development.md#enabling-a-feature-flag-locally-in-development). **(PREMIUM)** [feature flag](../../development/feature_flags/index.md#enabling-a-feature-flag-locally-in-development). **(PREMIUM)**
- [Repository](repository_analytics.md). **(FREE)** - [Repository](repository_analytics.md). **(FREE)**
- [Value Stream](value_stream_analytics.md). **(FREE)** - [Value Stream](value_stream_analytics.md). **(FREE)**
...@@ -242,7 +242,7 @@ a [beta feature](https://about.gitlab.com/handbook/product/#beta). ...@@ -242,7 +242,7 @@ a [beta feature](https://about.gitlab.com/handbook/product/#beta).
For a group, you can view how many merge requests, issues, and members were created in the last 90 days. For a group, you can view how many merge requests, issues, and members were created in the last 90 days.
These Group Activity Analytics can be enabled with the `group_activity_analytics` [feature flag](../../development/feature_flags/development.md#enabling-a-feature-flag-locally-in-development). These Group Activity Analytics can be enabled with the `group_activity_analytics` [feature flag](../../development/feature_flags/index.md#enabling-a-feature-flag-locally-in-development).
![Recent Group Activity](img/group_activity_analytics_v13_10.png) ![Recent Group Activity](img/group_activity_analytics_v13_10.png)
......
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