diff options
Diffstat (limited to 'doc/development/feature_flags')
| -rw-r--r-- | doc/development/feature_flags/controls.md | 19 | ||||
| -rw-r--r-- | doc/development/feature_flags/index.md | 16 |
2 files changed, 17 insertions, 18 deletions
diff --git a/doc/development/feature_flags/controls.md b/doc/development/feature_flags/controls.md index 63dad3070c7..e6c3c20d50b 100644 --- a/doc/development/feature_flags/controls.md +++ b/doc/development/feature_flags/controls.md @@ -2,15 +2,18 @@ type: reference, dev stage: none group: Development -info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments-to-development-guidelines" +info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-development-guidelines" --- -# Feature flag controls +# Use ChatOps to enable and disable feature flags -## Access +NOTE: +This document explains how to contribute to the development of the GitLab product. +If you want to use feature flags to show and hide functionality in your own applications, +view [this feature flags information](../../operations/feature_flags.md) instead. -To be able to turn on/off features behind feature flags in any of the -GitLab Inc. provided environments such as staging and production, you need to +To turn on/off features behind feature flags in any of the +GitLab-provided environments, like staging and production, you need to have access to the [ChatOps](../chatops_on_gitlabcom.md) bot. The ChatOps bot is currently running on the ops instance, which is different from [GitLab.com](https://gitlab.com) or [`dev.gitlab.org`](https://dev.gitlab.org). @@ -47,12 +50,12 @@ Note that all the examples in that file must be preceded by If you get an error "Whoops! This action is not allowed. This incident will be reported." that means your Slack account is not allowed to -change feature flags or you do not [have access](#access). +change feature flags or you do not have access. ### Enabling a feature for pre-production testing As a first step in a feature rollout, you should enable the feature on -[`about.staging.gitlab.com`](https://about.staging.gitlab.com) +[`staging.gitlab.com`](https://staging.gitlab.com) and [`dev.gitlab.org`](https://dev.gitlab.org). These two environments have different scopes. @@ -173,7 +176,7 @@ For project level features: Feature.enabled?(:feature_ice_cold_projects, project) ``` -If you are not certain what percentages to use, simply use the following steps: +If you are not certain what percentages to use, use the following steps: 1. 25% 1. 50% diff --git a/doc/development/feature_flags/index.md b/doc/development/feature_flags/index.md index 444b53f9c8d..f1cde4ae1ea 100644 --- a/doc/development/feature_flags/index.md +++ b/doc/development/feature_flags/index.md @@ -2,24 +2,20 @@ type: reference, dev stage: none group: Development -info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments-to-development-guidelines" +info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-development-guidelines" --- # Feature flags in the development of GitLab NOTE: -The documentation below covers feature flags used by GitLab to deploy its own features, which **is not** the same -as the [feature flags offered as part of the product](../../operations/feature_flags.md). - -This document provides guidelines on how to use feature flags -for the development of GitLab to conditionally and/or incrementally enable features -and test them in production/staging. +This document explains how to contribute to the development of the GitLab product. +If you want to use feature flags to show and hide functionality in your own applications, +view [this feature flags information](../../operations/feature_flags.md) instead. WARNING: All newly-introduced feature flags should be [disabled by default](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#feature-flags-in-gitlab-development). -NOTE: -This document is the subject of continued work as part of an epic to [improve internal usage of Feature Flags](https://gitlab.com/groups/gitlab-org/-/epics/3551). Raise any suggestions as new issues and attach them to the epic. +This document is the subject of continued work as part of an epic to [improve internal usage of feature flags](https://gitlab.com/groups/gitlab-org/-/epics/3551). Raise any suggestions as new issues and attach them to the epic. For an [overview of the feature flag lifecycle](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#feature-flag-lifecycle), or if you need help deciding [if you should use a feature flag](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags) or not, please see the [feature flag lifecycle](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/) handbook page. @@ -56,7 +52,7 @@ When the feature implementation is delivered among multiple merge requests: 1. When the feature is ready to be announced, create a merge request that adds documentation about the feature, including [documentation for the feature flag itself](../documentation/feature_flags.md), and a [changelog entry](#changelog). In the same merge request either flip the feature flag to - be **on by default** or remove it entirely in order to enable the new behavior. + be **on by default** or remove it entirely to enable the new behavior. One might be tempted to think that feature flags will delay the release of a feature by at least one month (= one release). This is not the case. A feature |