Welcome to mirror list, hosted at ThFree Co, Russian Federation.

gitlab.com/gitlab-org/gitlab-foss.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat (limited to 'doc/operations/feature_flags.md')
-rw-r--r--doc/operations/feature_flags.md30
1 files changed, 15 insertions, 15 deletions
diff --git a/doc/operations/feature_flags.md b/doc/operations/feature_flags.md
index b6e200c3ec4..68fc0fb9499 100644
--- a/doc/operations/feature_flags.md
+++ b/doc/operations/feature_flags.md
@@ -75,7 +75,7 @@ You can apply a feature flag strategy across multiple environments, without defi
the strategy multiple times.
GitLab feature flags use [Unleash](https://docs.getunleash.io/) as the feature flag
-engine. In Unleash, there are [strategies](https://docs.getunleash.io/user_guide/activation_strategy)
+engine. In Unleash, there are [strategies](https://docs.getunleash.io/reference/activation-strategies)
for granular feature flag controls. GitLab feature flags can have multiple strategies,
and the supported strategies are:
@@ -90,7 +90,7 @@ and selecting **Edit** (**{pencil}**).
### All users
-Enables the feature for all users. It uses the Standard (`default`) Unleash activation [strategy](https://docs.getunleash.io/user_guide/activation_strategy#standard).
+Enables the feature for all users. It uses the Standard (`default`) Unleash activation [strategy](https://docs.getunleash.io/reference/activation-strategies#standard).
### Percent Rollout
@@ -98,7 +98,7 @@ Enables the feature for all users. It uses the Standard (`default`) Unleash acti
Enables the feature for a percentage of page views, with configurable consistency
of behavior. This consistency is also known as stickiness. It uses the
-Gradual Rollout (`flexibleRollout`) Unleash activation [strategy](https://docs.getunleash.io/user_guide/activation_strategy#gradual-rollout).
+Gradual Rollout (`flexibleRollout`) Unleash activation [strategy](https://docs.getunleash.io/reference/activation-strategies#gradual-rollout).
You can configure the consistency to be based on:
@@ -126,7 +126,7 @@ Selecting **Random** provides inconsistent application behavior for individual u
### Percent of Users
Enables the feature for a percentage of authenticated users. It uses the Unleash activation strategy
-[`gradualRolloutUserId`](https://docs.getunleash.io/user_guide/activation_strategy#gradual-rollout).
+[`gradualRolloutUserId`](https://docs.getunleash.io/reference/activation-strategies#gradual-rollout).
For example, set a value of 15% to enable the feature for 15% of authenticated users.
@@ -135,7 +135,7 @@ The rollout percentage can be from 0% to 100%.
Stickiness (consistent application behavior for the same user) is guaranteed for authenticated users,
but not anonymous users.
-Note that [percent rollout](#percent-rollout) with a consistency based on **User IDs** has the same
+[Percent rollout](#percent-rollout) with a consistency based on **User IDs** has the same
behavior. We recommend using percent rollout because it's more flexible than percent of users
WARNING:
@@ -148,11 +148,11 @@ ID for the feature to be enabled. See the [Ruby example](#ruby-application-examp
> - [Updated](https://gitlab.com/gitlab-org/gitlab/-/issues/34363) to be defined per environment in GitLab 12.6.
Enables the feature for a list of target users. It is implemented
-using the Unleash UserIDs (`userWithId`) activation [strategy](https://docs.getunleash.io/user_guide/activation_strategy#userids).
+using the Unleash UserIDs (`userWithId`) activation [strategy](https://docs.getunleash.io/reference/activation-strategies#userids).
Enter user IDs as a comma-separated list of values (for example,
-`user@example.com, user2@example.com`, or `username1,username2,username3`, and so on). Note that
-user IDs are identifiers for your application users. They do not need to be GitLab users.
+`user@example.com, user2@example.com`, or `username1,username2,username3`, and so on).
+User IDs are identifiers for your application users. They do not need to be GitLab users.
WARNING:
The Unleash client **must** be given a user ID for the feature to be enabled for
@@ -163,7 +163,7 @@ target users. See the [Ruby example](#ruby-application-example) below.
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35930) in GitLab 13.1.
Enables the feature for lists of users created [in the feature flags UI](#create-a-user-list), or with the [feature flag user list API](../api/feature_flag_user_lists.md).
-Similar to [User IDs](#user-ids), it uses the Unleash UsersIDs (`userWithId`) activation [strategy](https://docs.getunleash.io/user_guide/activation_strategy#userids).
+Similar to [User IDs](#user-ids), it uses the Unleash UsersIDs (`userWithId`) activation [strategy](https://docs.getunleash.io/reference/activation-strategies#userids).
It's not possible to *disable* a feature for members of a user list, but you can achieve the same
effect by enabling a feature for a user list that doesn't contain the excluded users.
@@ -276,7 +276,7 @@ To get the access credentials that your application needs to communicate with Gi
For example, if the application runs for a production server, the **Application name**
could be `production` or similar. This value is used for the environment spec evaluation.
-Note that the meaning of these fields might change over time. For example, we're not sure if
+The meaning of these fields might change over time. For example, we're not sure if
**Instance ID** is a single token or multiple tokens, assigned to the **Environment**. Also,
**Application name** could describe the application version instead of the running environment.
@@ -372,7 +372,7 @@ end
### Unleash Proxy example
-As of [Unleash Proxy](https://docs.getunleash.io/sdks/unleash-proxy) version
+As of [Unleash Proxy](https://docs.getunleash.io/reference/unleash-proxy) version
0.2, the proxy is compatible with feature flags. To run a Docker container to
connect to your project's feature flags, run the following command:
@@ -389,7 +389,7 @@ docker run \
| Variable | Value |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
-| `UNLEASH_PROXY_SECRETS` | Shared secret used to configure an [Unleash Proxy client](https://docs.getunleash.io/sdks/unleash-proxy#how-to-connect-to-the-proxy). |
+| `UNLEASH_PROXY_SECRETS` | Shared secret used to configure an [Unleash Proxy client](https://docs.getunleash.io/reference/unleash-proxy#how-to-connect-to-the-proxy). |
| `UNLEASH_URL` | Your project's API URL. For more details, read [Get access credentials](#get-access-credentials). |
| `UNLEASH_INSTANCE_ID` | Your project's Instance ID. For more details, read [Get access credentials](#get-access-credentials). |
| `UNLEASH_APP_NAME` | The name of the environment the application runs in. For more details, read [Get access credentials](#get-access-credentials). |
@@ -416,7 +416,7 @@ In general, GitLab feature flags can be used in any applications,
however, if it's a large application, it could require an additional configuration in advance.
This section explains the performance factors to help your organization to identify
what's needed to be done before using the feature.
-Please read [How it works](#how-it-works) section before diving into the details.
+Read [How it works](#how-it-works) section before diving into the details.
### Maximum supported clients in application nodes
@@ -444,7 +444,7 @@ a fall-back mechanism when the server returns an error code.
For example, `unleash-ruby-client` reads flag data from the local backup so that
application can keep running in the current state.
-Please reads the documentation in a SDK project for more information.
+Read the documentation in a SDK project for more information.
### Self-managed GitLab
@@ -453,5 +453,5 @@ Functionality-wise, there are no differences. Both SaaS and self-managed behave
In terms of scalability, it's up to the spec of the GitLab instance.
For example, GitLab.com runs on HA architecture so that it can handle a lot of requests concurrently,
however, a self-managed instance runs on a low spec machine can't expect the same result.
-Please see [Reference architectures](../administration/reference_architectures/index.md)
+See [Reference architectures](../administration/reference_architectures/index.md)
for more information.