mirror of
https://github.com/Unleash/unleash.git
synced 2024-12-22 19:07:54 +01:00
d5fbd0b743
## What This (admittedly massive) PR updates the "physical" documentation structure and fixes url inconsistencies and SEO problems reported by marketing. The main points are: - remove or move directories : advanced, user_guide, deploy, api - move the files contained within to the appropriate one of topics, how-to, tutorials, or reference - update internal doc links and product links to the content - create client-side redirects for all the urls that have changed. A number of the files have been renamed in small ways to better match their url and to make them easier to find. Additionally, the top-level api directory has been moved to /reference/api/legacy/unleash (see the discussion points section for more on this). ## Why When moving our doc structure to diataxis a while back, we left the "physical' files lying where they were, because it didn't matter much to the new structure. However, that did introduce some inconsistencies with where you place docs and how we organize them. There's also the discrepancies in whether urls us underscores or hyphens (which isn't necessarily the same as their file name), which has been annoying me for a while, but now has also been raised by marketing as an issue in terms of SEO. ## Discussion points The old, hand-written API docs have been moved from /api to /reference/api/legacy/unleash. There _is_ a /reference/api/unleash directory, but this is being populated by the OpenAPI plugin, and mixing those could only cause trouble. However, I'm unsure about putting /legacy/ in the title, because the API isn't legacy, the docs are. Maybe we could use another path? Like /old-docs/ or something? I'd appreciate some input on this.
40 lines
3.6 KiB
Plaintext
40 lines
3.6 KiB
Plaintext
---
|
|
title: Feature Toggles
|
|
---
|
|
|
|
Feature toggles are the central concept that we built Unleash around. In Unleash, feature toggles are organized within [projects](../reference/projects.md). Feature toggles can have different [activation strategies](../reference/activation-strategies.md) for each of their project's [environments](../reference/environments.md), and can also be given [variants](../reference/feature-toggle-variants.md) to facilitate A/B testing.
|
|
|
|
## Configuration options
|
|
|
|
Each feature toggle has the following configuration options
|
|
|
|
| Option | Required? | Default value | Description |
|
|
| --- | --- | --- | --- |
|
|
| name | Yes | N/A | The feature toggle's name. Must be URL-friendly according to [section 2.3 of RFC 3986](https://www.rfc-editor.org/rfc/rfc3986#section-2.3) and must be unique within your Unleash instance. Must be between 1 and 100 characters long, inclusive. |
|
|
| feature toggle type | Yes | Release | The [feature toggle's type](../reference/feature-toggle-types.md). |
|
|
| project | Yes | The [default project](../reference/projects.md#the-default-project). When created from a project page in the admin UI, that project will be the default value instead. | The [project](../reference/projects.md) that should contain the feature toggle. |
|
|
| description | No | N/A | A description of the feature toggle's purpose. |
|
|
| enable impression data | Yes | No | Whether to enable [impression data](../reference/impression-data.md) for this toggle or not. |
|
|
|
|
## Environments
|
|
|
|
You probably won't want to use the same configuration to enable a toggle in development as you do in production. That's why feature toggles have different activation strategy configurations for each environment.
|
|
|
|
You can enable and disable a toggle independently in each of the [project's environments](../reference/projects.md#projects-and-environments). When you disable a toggle in an environment, it will always evaluate to false in that environment. When you enable a toggle in an environment, the toggle will evaluate to true or false depending on its activation strategies.
|
|
|
|
Refer to the [documentation on environments](../reference/environments.md) for more details on how environments work.
|
|
|
|
## Activation strategies
|
|
|
|
To enable a feature in an environment, you must assign it at least one activation strategy. A feature toggle's activation strategies determine whether the toggle gets enabled for a particular [Unleash context](../reference/unleash-context.md) (typically a user). When using multiple strategies in a single environment, only a single strategy needs to evaluate to true for the toggle to get enabled for a user. Whenever Unleash evaluates a toggle, it will evaluate strategies in the current environment until one of them resolves to true. If no strategies resolve to true, then the toggle's value is false.
|
|
|
|
Refer to the [activation strategies documentation](../reference/activation-strategies.md) for a detailed description of all the built-in strategies.
|
|
|
|
## Variants
|
|
|
|
[Variants](../reference/feature-toggle-variants.md) adds another dimension of flexibility to feature toggles. Each feature toggle can be assigned any number of variants which will then get distributed amongst your users based on your choice of [context field](../reference/unleash-context.md#structure). You can find out more about variants in the [variants docs](../reference/feature-toggle-variants.md).
|
|
|
|
### Creating toggles with payloads
|
|
|
|
While variants are most often used for A/B testing and the like, you can also use variants to assign a constant payload to a toggle. If you give a toggle only a single variant and that variant has a payload, then all users variants will receive that payload.
|