mirror of
https://github.com/Unleash/unleash.git
synced 2025-01-25 00:07:47 +01:00
Jaanus Sellin
GitHub
parent
8b5e39c997
commit
83dfdc7905
@ -8,21 +8,21 @@ Before Unleash 4.16, strategy constraints were only available to Unleash Pro and
|
||||
|
||||
:::
|
||||
|
||||
This guide shows you how to add [strategy constraints](../reference/strategy-constraints.md) to your feature toggles via the admin UI. For information on how to interact with strategy constraints from an [Unleash client SDK](../reference/sdks/index.md), visit the specific SDKs documentation or see [the relevant section in the strategy constraints documentation](../reference/strategy-constraints.md#sdks 'strategy constraints documentation, section on interacting with constraints from client SDKs').
|
||||
This guide shows you how to add [strategy constraints](../reference/strategy-constraints.md) to your feature flags via the admin UI. For information on how to interact with strategy constraints from an [Unleash client SDK](../reference/sdks/index.md), visit the specific SDKs documentation or see [the relevant section in the strategy constraints documentation](../reference/strategy-constraints.md#sdks 'strategy constraints documentation, section on interacting with constraints from client SDKs').
|
||||
|
||||
## Prerequisites
|
||||
|
||||
You'll need to have an existing feature toggle with a defined strategy to add a constraint. The rest of this guide assumes you have a specific strategy that you're working with.
|
||||
You'll need to have an existing feature flag with a defined strategy to add a constraint. The rest of this guide assumes you have a specific strategy that you're working with.
|
||||
|
||||
## Step 1: Open the constraints menu {#step-1}
|
||||
|
||||
On the strategy you're working with, find and select the "edit strategy" button.
|
||||
|
||||
|
||||
|
||||
|
||||
On the "edit strategy" screen, select the "add constraint" button to open the constraints menu.
|
||||
|
||||
|
||||
|
||||
|
||||
## Step 2: Add and configure the constraint {#step-2}
|
||||
|
||||
@ -36,7 +36,7 @@ Refer to [the _constraint structure_ section of the strategy constraints referen
|
||||
|
||||
## Step 3: Save the strategy {#step-3}
|
||||
|
||||
|
||||
|
||||
|
||||
## How to update existing constraints
|
||||
|
||||
|
||||
@ -8,7 +8,7 @@ Environment cloning was made available in Unleash 4.19.
|
||||
|
||||
:::
|
||||
|
||||
[Environment cloning](../reference/environments.md#cloning-environments) enables Unleash admins to duplicate existing environments, including all feature toggles strategies and their state.
|
||||
[Environment cloning](../reference/environments.md#cloning-environments) enables Unleash admins to duplicate existing environments, including all feature flags strategies and their state.
|
||||
|
||||
## Step 1: Navigate to the environments page {#step-1}
|
||||
|
||||
|
||||
@ -2,13 +2,13 @@
|
||||
title: How to create a feature flag
|
||||
---
|
||||
|
||||
:::info Feature flags or feature toggles?
|
||||
:::info Feature flags or feature flags?
|
||||
|
||||
This document uses **feature flags** and **feature toggles** interchangeably. Some people prefer flag; others prefer toggle. We use both - they are synonyms for us.
|
||||
This document uses **feature flags** and **feature flags** interchangeably. Some people prefer flag; others prefer flag. We use both - they are synonyms for us.
|
||||
|
||||
:::
|
||||
|
||||
Feature Flags (or [Feature toggles](../reference/feature-toggles.mdx) in the UI) are the foundation of Unleash. They are at the core of everything we do and are a fundamental building block in any feature management system. This guide shows you how to create feature flags in Unleash and how to add any optional constraints, segments, variants, and more. Links to learn more about these concepts will be scattered throughout the text.
|
||||
Feature Flags (or [Feature flags](../reference/feature-toggles.mdx) in the UI) are the foundation of Unleash. They are at the core of everything we do and are a fundamental building block in any feature management system. This guide shows you how to create feature flags in Unleash and how to add any optional constraints, segments, variants, and more. Links to learn more about these concepts will be scattered throughout the text.
|
||||
|
||||
You can perform every action both via the UI and the admin API. This guide includes screenshots to highlight the relevant UI controls and links to the relevant API methods for each step.
|
||||
|
||||
@ -26,12 +26,12 @@ To perform all the steps in this guide, you will need:
|
||||
- A project to hold the flag
|
||||
- A user with an **editor** or **admin** role OR a user with the following permissions inside the target project:
|
||||
- **[project-level permissions](../reference/rbac.md#project-permissions)**
|
||||
- create feature toggles
|
||||
- create feature flags
|
||||
- **[environment-level permissions](../reference/rbac.md#environment-permissions)**
|
||||
- create/edit variants[^1]
|
||||
- create activation strategies
|
||||
- update activation strategies
|
||||
- enable/disable toggles
|
||||
- enable/disable flags
|
||||
|
||||
:::info roles
|
||||
|
||||
@ -41,17 +41,17 @@ Refer to [the documentation on role-based access control](../reference/rbac.md)
|
||||
|
||||
## Required steps
|
||||
|
||||
This section takes you through the required steps to create and activate a feature toggle. It assumes that you have all the prerequisites from the previous section done.
|
||||
This section takes you through the required steps to create and activate a feature flag. It assumes that you have all the prerequisites from the previous section done.
|
||||
|
||||
### Step 1: Create a toggle {#step-1}
|
||||
### Step 1: Create a flag {#step-1}
|
||||
|
||||
:::tip API: create a toggle
|
||||
:::tip API: create a flag
|
||||
|
||||
Use the [Admin API endpoint for creating a feature toggle](/reference/api/legacy/unleash/admin/features-v2.md#create-toggle). The payload accepts all the same fields as the Admin UI form. The Admin UI also displays the corresponding cURL command when you use the form.
|
||||
Use the [Admin API endpoint for creating a feature flag](/reference/api/legacy/unleash/admin/features-v2.md#create-toggle). The payload accepts all the same fields as the Admin UI form. The Admin UI also displays the corresponding cURL command when you use the form.
|
||||
|
||||
:::
|
||||
|
||||
In the project that you want to create the toggle in, use the "new feature toggle" button and fill the form out with your desired configuration. Refer to the [feature toggle reference documentation](../reference/feature-toggles.mdx) for the full list of configuration options and explanations.
|
||||
In the project that you want to create the flag in, use the "new feature flag" button and fill the form out with your desired configuration. Refer to the [feature flag reference documentation](../reference/feature-toggles.mdx) for the full list of configuration options and explanations.
|
||||
|
||||
|
||||
|
||||
@ -59,29 +59,29 @@ In the project that you want to create the toggle in, use the "new feature toggl
|
||||
|
||||
:::tip API: Add a strategy
|
||||
|
||||
Use the [API for adding a strategy to a feature toggle](/reference/api/legacy/unleash/admin/features-v2.md#add-strategy). You can find the configuration options for each strategy in the [activation strategy reference documentation](../reference/activation-strategies.md).
|
||||
Use the [API for adding a strategy to a feature flag](/reference/api/legacy/unleash/admin/features-v2.md#add-strategy). You can find the configuration options for each strategy in the [activation strategy reference documentation](../reference/activation-strategies.md).
|
||||
|
||||
:::
|
||||
|
||||
Decide which environment you want to enable the toggle in. Select that environment and add an activation strategy. Different activation strategies will act differently as described in the [activation strategy documentation](../reference/activation-strategies.md). The configuration for each strategy differs accordingly. After selecting a strategy, complete the steps to configure it.
|
||||
Decide which environment you want to enable the flag in. Select that environment and add an activation strategy. Different activation strategies will act differently as described in the [activation strategy documentation](../reference/activation-strategies.md). The configuration for each strategy differs accordingly. After selecting a strategy, complete the steps to configure it.
|
||||
|
||||
|
||||
|
||||
### Step 3: Enable the toggle {#step-3}
|
||||
### Step 3: Enable the flag {#step-3}
|
||||
|
||||
:::tip API: Enable a toggle
|
||||
:::tip API: Enable a flag
|
||||
|
||||
Use the [API for enabling an environment for a toggle](/reference/api/legacy/unleash/admin/features-v2.md#enable-env) and specify the environment you'd like to enable.
|
||||
Use the [API for enabling an environment for a flag](/reference/api/legacy/unleash/admin/features-v2.md#enable-env) and specify the environment you'd like to enable.
|
||||
|
||||
:::
|
||||
|
||||
Use the environments toggles to switch on the environment that you chose above. Depending on the activation strategy you added in the previous step, the toggle should now evaluate to true or false depending on the Unleash context you provide it.
|
||||
Use the environments flags to switch on the environment that you chose above. Depending on the activation strategy you added in the previous step, the flag should now evaluate to true or false depending on the Unleash context you provide it.
|
||||
|
||||
|
||||
|
||||
## Optional steps
|
||||
|
||||
These optional steps allow you to further configure your feature toggles to add optional payloads, variants for A/B testing, more detailed user targeting and exceptions/overrides.
|
||||
These optional steps allow you to further configure your feature flags to add optional payloads, variants for A/B testing, more detailed user targeting and exceptions/overrides.
|
||||
|
||||
### Add constraints and segmentation
|
||||
|
||||
@ -95,7 +95,7 @@ To add constraints and segmentation, use the "edit strategy" button for the desi
|
||||
|
||||
:::info
|
||||
|
||||
Constraints aren't fixed and can be changed later to further narrow your audience. You can add them either when you add a strategy to a toggle or at any point thereafter.
|
||||
Constraints aren't fixed and can be changed later to further narrow your audience. You can add them either when you add a strategy to a flag or at any point thereafter.
|
||||
|
||||
:::
|
||||
|
||||
@ -131,7 +131,7 @@ In the strategy configuration screen for the strategy that you want to configure
|
||||
|
||||
:::info
|
||||
|
||||
This can be done at any point after you've created your toggle.
|
||||
This can be done at any point after you've created your flag.
|
||||
|
||||
:::
|
||||
|
||||
@ -141,7 +141,7 @@ Use the [update variants endpoint](/reference/api/legacy/unleash/admin/features-
|
||||
|
||||
:::
|
||||
|
||||
[Variants](../reference/feature-toggle-variants.md) give you the ability to further target your users and split them into groups of your choosing, such as for A/B testing. On the toggle overview page, select the variants tab. Use the "new variant" button to add the variants that you want.
|
||||
[Variants](../reference/feature-toggle-variants.md) give you the ability to further target your users and split them into groups of your choosing, such as for A/B testing. On the flag overview page, select the variants tab. Use the "new variant" button to add the variants that you want.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -15,7 +15,7 @@ Api admin state is deprecated from version 5. We recommend using the new [Enviro
|
||||
|
||||
:::
|
||||
|
||||
Unleash supports import and export of feature toggles and strategies at startup and during runtime. The main purpose of the import/export feature is to bootstrap new Unleash instances with feature toggles and their configuration. If you are looking for a granular way to keep separate Unleash instances in sync we strongly recommend that you take a look at the Unleash Admin APIs.
|
||||
Unleash supports import and export of feature flags and strategies at startup and during runtime. The main purpose of the import/export feature is to bootstrap new Unleash instances with feature flags and their configuration. If you are looking for a granular way to keep separate Unleash instances in sync we strongly recommend that you take a look at the Unleash Admin APIs.
|
||||
|
||||
The import mechanism guarantees that:
|
||||
- all imported features will be non-archived
|
||||
@ -48,7 +48,7 @@ await stateService.importFile({file: 'exported-data.yml', userName: 'import', dr
|
||||
|
||||
If you want the database to be cleaned before import (all strategies and features will be removed), set the `dropBeforeImport` parameter.
|
||||
|
||||
It is also possible to not override existing feature toggles (and strategies) by using the `keepExisting` parameter.
|
||||
It is also possible to not override existing feature flags (and strategies) by using the `keepExisting` parameter.
|
||||
|
||||
### API Export {#api-export}
|
||||
|
||||
@ -86,7 +86,7 @@ You can customize the import with query parameters:
|
||||
| Parameter | Default | Description |
|
||||
| --- | --- | --- |
|
||||
| drop | `false` | If the database should be cleaned before import (see comment below) |
|
||||
| keep | `true` | If true, the existing feature toggles and strategies will not be overridden |
|
||||
| keep | `true` | If true, the existing feature flags and strategies will not be overridden |
|
||||
|
||||
If you want the database to be cleaned before import (**all strategies and features will be removed**), specify a `drop` query parameter.
|
||||
|
||||
@ -98,11 +98,11 @@ You should be cautious about using the `drop` query parameter in production envi
|
||||
|
||||
Example usage:
|
||||
|
||||
<ApiRequest verb="post" url="api/admin/state/import" payload={{ "version": 3, "features": [{"name": "a-feature-toggle", "enabled": true, "description": "#1 feature-toggle"}] }} title="Import data into Unleash."/>
|
||||
<ApiRequest verb="post" url="api/admin/state/import" payload={{ "version": 3, "features": [{"name": "a-feature-flag", "enabled": true, "description": "#1 feature-flag"}] }} title="Import data into Unleash."/>
|
||||
|
||||
## Startup import {#startup-import}
|
||||
|
||||
You can import toggles and strategies on startup by using an import file in JSON or YAML format. As with other forms of imports, you can also choose to remove the current toggle and strategy configuration in the database before importing.
|
||||
You can import flags and strategies on startup by using an import file in JSON or YAML format. As with other forms of imports, you can also choose to remove the current flag and strategy configuration in the database before importing.
|
||||
|
||||
Unleash lets you do this both via configuration parameters and environment variables. The relevant parameters/variables are:
|
||||
|
||||
@ -113,7 +113,7 @@ Unleash lets you do this both via configuration parameters and environment varia
|
||||
|
||||
### Importing files
|
||||
|
||||
To import strategies and toggles from a file (called `configuration.yml` in the examples below), either
|
||||
To import strategies and flags from a file (called `configuration.yml` in the examples below), either
|
||||
- use the `importFile` parameter to point to the file (you can also pass this into the `unleash.start()` entry point)
|
||||
``` shell
|
||||
unleash-server --databaseUrl [...] \
|
||||
@ -131,7 +131,7 @@ To import strategies and toggles from a file (called `configuration.yml` in the
|
||||
You should never use this in production environments.
|
||||
:::
|
||||
|
||||
To remove pre-existing feature toggles and strategies in the database before importing the new ones, either:
|
||||
To remove pre-existing feature flags and strategies in the database before importing the new ones, either:
|
||||
- add the `dropBeforeImport` flag to the `unleash-server` command (or to `unleash.start()`)
|
||||
``` shell
|
||||
unleash-server --databaseUrl [...] \
|
||||
|
||||
@ -10,7 +10,7 @@ Placeholders in the code samples below are delimited by angle brackets (i.e. `<p
|
||||
|
||||
:::
|
||||
|
||||
The [Unleash Proxy](../generated/unleash-proxy.md) provides a way for you to consume feature toggles in [front-end clients](../reference/sdks/index.md#front-end-sdks), such as the [JavaScript Proxy client](/docs/generated/sdks/client-side/javascript-browser.md) and [React Proxy client](/docs/generated/sdks/client-side/react.md).
|
||||
The [Unleash Proxy](../generated/unleash-proxy.md) provides a way for you to consume feature flags in [front-end clients](../reference/sdks/index.md#front-end-sdks), such as the [JavaScript Proxy client](/docs/generated/sdks/client-side/javascript-browser.md) and [React Proxy client](/docs/generated/sdks/client-side/react.md).
|
||||
|
||||
Depending on your setup, the Proxy is most easily run in one of two ways, depending on your situation:
|
||||
|
||||
@ -107,6 +107,6 @@ app.listen(port, () =>
|
||||
|
||||
## Verify that the proxy is working
|
||||
|
||||
When the proxy process has started up correctly, you can start querying its `/proxy` endpoint. If it's running correctly, you'll get back a JSON object with a list of toggles. The list may be empty if you haven't added any toggles for the corresponding project/environment yet.
|
||||
When the proxy process has started up correctly, you can start querying its `/proxy` endpoint. If it's running correctly, you'll get back a JSON object with a list of flags. The list may be empty if you haven't added any flags for the corresponding project/environment yet.
|
||||
|
||||
<ApiRequest verb="get" url="proxy" endpointType="proxy" title="Request toggles from the Unleash Proxy"/>
|
||||
<ApiRequest verb="get" url="proxy" endpointType="proxy" title="Request flags from the Unleash Proxy"/>
|
||||
|
||||
@ -23,7 +23,7 @@ In this guide we'll schedule a feature for release at some point in time. The ex
|
||||
This guide assumes that you've got the following:
|
||||
- some basic experience with Unleash
|
||||
- a running instance of Unleash and connected clients (where applicable)
|
||||
- an existing feature toggle that you want to schedule the release for
|
||||
- an existing feature flag that you want to schedule the release for
|
||||
|
||||
## Schedule feature releases with strategy constraints {#strategy-constraints}
|
||||
|
||||
@ -41,7 +41,7 @@ To schedule a feature release via the UI:
|
||||
|
||||
#### Scheduling a release via the API
|
||||
|
||||
To add an activation strategy via the Admin API, use the feature's `strategies` endpoint to add a new strategy (see the [API documentation for adding strategies to feature toggles](/reference/api/legacy/unleash/admin/features-v2.md#add-strategy) for more details).
|
||||
To add an activation strategy via the Admin API, use the feature's `strategies` endpoint to add a new strategy (see the [API documentation for adding strategies to feature flags](/reference/api/legacy/unleash/admin/features-v2.md#add-strategy) for more details).
|
||||
|
||||
The payload's `"name"` property should contain the name of the strategy to apply (see [activation strategies reference documentation](../reference/activation-strategies.md) for all built-in strategies' _modeling names_).
|
||||
|
||||
@ -74,7 +74,7 @@ To schedule feature releases without using strategy constraints, you can use cus
|
||||
2. Give the strategy a required string parameter where the user can enter the time at which the feature should activate. Be sure to describe the format that the user must adhere to.
|
||||
3. Save the strategy
|
||||
|
||||
[**Apply the strategy** to the feature toggle](../how-to/how-to-use-custom-strategies.md#step-2) you want to schedule.
|
||||
[**Apply the strategy** to the feature flag](../how-to/how-to-use-custom-strategies.md#step-2) you want to schedule.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -10,13 +10,13 @@ This is an experimental feature
|
||||
|
||||
# Unleash Instance Synchronization Script
|
||||
|
||||
This script allows you to synchronize feature toggles between two Unleash instances using the export and import APIs provided by Unleash. The script exports feature toggles from the source instance and imports them into the target instance.
|
||||
This script allows you to synchronize feature flags between two Unleash instances using the export and import APIs provided by Unleash. The script exports feature flags from the source instance and imports them into the target instance.
|
||||
|
||||
You can find this script in the following location within the project:
|
||||
|
||||
`scripts/promote.sh`
|
||||
|
||||
This script can also be integrated into a continuous deployment pipeline, allowing you to automatically synchronize feature toggles between instances at a frequency determined by your pipeline configuration.
|
||||
This script can also be integrated into a continuous deployment pipeline, allowing you to automatically synchronize feature flags between instances at a frequency determined by your pipeline configuration.
|
||||
|
||||
## Configuration
|
||||
|
||||
@ -28,8 +28,8 @@ To synchronize two Unleash instances, you need to configure each instance with t
|
||||
Example: `SOURCE_URL="http://localhost:4242/api/admin/features-batch/export"`
|
||||
- `SOURCE_API_TOKEN`: The API token for the source Unleash instance. This can be a personal access token or a service account token with enough privileges to perform the export operation.
|
||||
Example: `SOURCE_API_TOKEN="user:98b555423fa020a3e67267fb8462fdeea13a1d62e7ea61d5fe4f3022"`
|
||||
- `SOURCE_ENV`: The environment name for the source instance. Only feature toggles matching this environment will be exported.
|
||||
- `SOURCE_TAG`: The tag to filter feature toggles for export.
|
||||
- `SOURCE_ENV`: The environment name for the source instance. Only feature flags matching this environment will be exported.
|
||||
- `SOURCE_TAG`: The tag to filter feature flags for export.
|
||||
|
||||
### Target Unleash Instance
|
||||
|
||||
@ -37,15 +37,15 @@ To synchronize two Unleash instances, you need to configure each instance with t
|
||||
Example: `TARGET_URL="http://localhost:4242/api/admin/features-batch/import"`
|
||||
- `TARGET_API_TOKEN`: The API token for the target Unleash instance. This can be a personal access token or a service account token with enough privileges to perform the import operation.
|
||||
Example: `TARGET_API_TOKEN="user:98b555423fa020a3e67267fb8462fdeea13a1d62e7ea61d5fe4f3022"`
|
||||
- `TARGET_PROJECT`: The project name for the target instance where the feature toggles will be imported.
|
||||
- `TARGET_PROJECT`: The project name for the target instance where the feature flags will be imported.
|
||||
- `TARGET_ENV`: The environment name for the target instance.
|
||||
|
||||
## Process
|
||||
|
||||
The script performs the following steps:
|
||||
|
||||
1. Export feature toggles from the source instance based on the specified tag and environment.
|
||||
2. Import the exported feature toggles into the target instance under the specified project and environment.
|
||||
1. Export feature flags from the source instance based on the specified tag and environment.
|
||||
2. Import the exported feature flags into the target instance under the specified project and environment.
|
||||
|
||||
If change requests are enabled in the target project, the import process will go through the change request process, allowing you to review the changes before applying them.
|
||||
|
||||
|
||||
@ -10,9 +10,9 @@ The downside of using a custom activation strategy instead of constraints is tha
|
||||
:::
|
||||
|
||||
|
||||
This guide takes you through how to use [custom activation strategies](../reference/custom-activation-strategies.md) with Unleash. We'll go through how you define a custom strategy in the admin UI, how you add it to a toggle, and how you'd implement it in a [client SDK](../reference/sdks/index.md).
|
||||
This guide takes you through how to use [custom activation strategies](../reference/custom-activation-strategies.md) with Unleash. We'll go through how you define a custom strategy in the admin UI, how you add it to a flag, and how you'd implement it in a [client SDK](../reference/sdks/index.md).
|
||||
|
||||
In this example we want to define an activation strategy offers a scheduled release of a feature toggle. This means that we want the feature toggle to be activated after a given date and time.
|
||||
In this example we want to define an activation strategy offers a scheduled release of a feature flag. This means that we want the feature flag to be activated after a given date and time.
|
||||
|
||||
## Step 1: Define your custom strategy {#step-1}
|
||||
|
||||
@ -22,11 +22,11 @@ In this example we want to define an activation strategy offers a scheduled rele
|
||||
|
||||
2. **Define your strategy**. Use the "Add new strategy" button to open the strategy creation form. Fill in the form to define your strategy. Refer to [the custom strategy reference documentation](../reference/custom-activation-strategies.md#definition) for a full list of options.
|
||||
|
||||
|
||||
|
||||
|
||||
## Step 2: Apply your custom strategy to a feature toggle {#step-2}
|
||||
## Step 2: Apply your custom strategy to a feature flag {#step-2}
|
||||
|
||||
**Navigate to your feature toggle** and **apply the strategy** you just created.
|
||||
**Navigate to your feature flag** and **apply the strategy** you just created.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -20,7 +20,7 @@ If you need an API token to use in a client SDK you should create a "client toke
|
||||
|
||||
Now that you have an access token with admin privileges we can use that to perform changes in our Unleash instance.
|
||||
|
||||
In the example below we will use the [Unleash Admin API](/reference/api/legacy/unleash/admin/features.md) to enable the “Demo” feature toggle using curl.
|
||||
In the example below we will use the [Unleash Admin API](/reference/api/legacy/unleash/admin/features.md) to enable the “Demo” feature flag using curl.
|
||||
|
||||
```sh
|
||||
curl -X POST -H "Content-Type: application/json" \
|
||||
@ -28,9 +28,9 @@ curl -X POST -H "Content-Type: application/json" \
|
||||
https://app.unleash-hosted.com/demo/api/admin/features/Demo/toggle/on
|
||||
```
|
||||
|
||||
**Great success!** We have now enabled the feature toggle. We can also verify that it was actually changed by the API user by navigating to the Event log (history) for this feature toggle.
|
||||
**Great success!** We have now enabled the feature flag. We can also verify that it was actually changed by the API user by navigating to the Event log (history) for this feature flag.
|
||||
|
||||
|
||||
|
||||
|
||||
## API overview {#api-overview}
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: API Tokens and Client Keys
|
||||
---
|
||||
|
||||
For Unleash to be of any use, it requires at least a server and a [consuming client](../reference/sdks/index.md). More advanced use cases may call for multiple clients, automated feature toggle updates, the [Unleash proxy](../generated/unleash-proxy.md) and [Unleash proxy clients](../reference/sdks/index.md#front-end-sdks), and more. To facilitate communication between all these moving parts, Unleash uses a system of API tokens and client keys, all with a specific purpose in mind.
|
||||
For Unleash to be of any use, it requires at least a server and a [consuming client](../reference/sdks/index.md). More advanced use cases may call for multiple clients, automated feature flag updates, the [Unleash proxy](../generated/unleash-proxy.md) and [Unleash proxy clients](../reference/sdks/index.md#front-end-sdks), and more. To facilitate communication between all these moving parts, Unleash uses a system of API tokens and client keys, all with a specific purpose in mind.
|
||||
|
||||
This document details the three kinds of tokens and keys that you will need to fully connect any Unleash system:
|
||||
|
||||
@ -60,11 +60,11 @@ Similarly, any project members with the `CREATE_PROJECT_API_TOKEN` permission ca
|
||||
|
||||
Use admin tokens to:
|
||||
|
||||
- Automate Unleash behavior such as creating feature toggles, projects, etc.
|
||||
- Automate Unleash behavior such as creating feature flags, projects, etc.
|
||||
- Write custom Unleash UIs to replace the default Unleash admin UI.
|
||||
Do **not** use admin tokens for:
|
||||
|
||||
- [Client SDKs](../reference/sdks/index.md): You will _not_ be able to read toggle data from multiple environments. Use [client tokens](#client-tokens) instead.
|
||||
- [Client SDKs](../reference/sdks/index.md): You will _not_ be able to read flag data from multiple environments. Use [client tokens](#client-tokens) instead.
|
||||
|
||||
Support for scoped admin tokens with more fine-grained permissions is currently in the planning stage.
|
||||
|
||||
@ -98,14 +98,14 @@ It is possible to set a token's expiration date to **never**. However, a token t
|
||||
|
||||
Do **not** use personal access tokens for:
|
||||
|
||||
- [Client SDKs](../reference/sdks/index.md): You will _not_ be able to read toggle data from multiple environments. Use [client tokens](#client-tokens) instead.
|
||||
- [Client SDKs](../reference/sdks/index.md): You will _not_ be able to read flag data from multiple environments. Use [client tokens](#client-tokens) instead.
|
||||
- Write custom Unleash UIs: Personal access tokens may expire and their permissions may change. It's better to use [admin tokens](#admin-tokens) tokens instead.
|
||||
|
||||
### Client tokens
|
||||
|
||||
**Client tokens** are intended for use in [server-side client SDKs](../reference/sdks/index.md#server-side-sdks) (including the Unleash Proxy) and grant the user permissions to:
|
||||
|
||||
- Read feature toggle information
|
||||
- Read feature flag information
|
||||
- Register applications with the Unleash server
|
||||
- Send usage metrics
|
||||
|
||||
@ -128,7 +128,7 @@ Do **not** use client tokens in:
|
||||
|
||||
**Front-end tokens** are used with [front-end SDKs](../reference/sdks/index.md#front-end-sdks) when used with the [Unleash front-end API](./front-end-api.md). They grant the user permission to:
|
||||
|
||||
- Read the enabled toggled for a given context
|
||||
- Read the enabled flagd for a given context
|
||||
- Register applications with the Unleash server
|
||||
- Send usage metrics
|
||||
|
||||
@ -180,15 +180,15 @@ Personal access tokens do not contain project or environment information, since
|
||||
|
||||
Some example client tokens are:
|
||||
|
||||
- A token with access to toggles in the "development" environment of a single project, "project-a":
|
||||
- A token with access to flags in the "development" environment of a single project, "project-a":
|
||||
```
|
||||
project-a:development.be44368985f7fb3237c584ef86f3d6bdada42ddbd63a019d26955178
|
||||
```
|
||||
- A token with access to toggles in the "production" environment multiple projects:
|
||||
- A token with access to flags in the "production" environment multiple projects:
|
||||
```
|
||||
[]:production.be44368985f7fb3237c584ef86f3d6bdada42ddbd63a019d26955178
|
||||
```
|
||||
- A token with access to toggles in the "development" environment of all projects:
|
||||
- A token with access to flags in the "development" environment of all projects:
|
||||
```
|
||||
*:development.be44368985f7fb3237c584ef86f3d6bdada42ddbd63a019d26955178
|
||||
```
|
||||
|
||||
@ -4,7 +4,7 @@ title: /api/client/features
|
||||
|
||||
> In order to access the client API endpoints you need to identify yourself. Unless you're using the `none` authentication method, you'll need to [create a CLIENT token](/how-to/how-to-create-api-tokens.mdx) and add an Authorization header using the token.
|
||||
|
||||
### Fetching Feature Toggles {#fetching-feature-toggles}
|
||||
### Fetching Feature Flags {#fetching-feature-toggles}
|
||||
|
||||
`GET: http://unleash.host.com/api/client/features`
|
||||
|
||||
@ -13,7 +13,7 @@ title: /api/client/features
|
||||
- UNLEASH-APPNAME: appName
|
||||
- UNLEASH-INSTANCEID: instanceId
|
||||
|
||||
This endpoint is the one all clients should use to fetch all available feature toggles from the _unleash-server_. The response returns all active feature toggles and their current strategy configuration. A feature toggle will have _at least_ one configured strategy. A strategy will have a `name` and `parameters` map.
|
||||
This endpoint is the one all clients should use to fetch all available feature flags from the _unleash-server_. The response returns all active feature flags and their current strategy configuration. A feature flag will have _at least_ one configured strategy. A strategy will have a `name` and `parameters` map.
|
||||
|
||||
> _Note:_ Clients should prefer the `strategies` property. Legacy properties (`strategy` & `parameters`) will be kept until **version 2** of the format.
|
||||
|
||||
@ -67,7 +67,7 @@ This endpoint should never return anything besides a valid _20X or 304-response_
|
||||
}
|
||||
```
|
||||
|
||||
#### Filter feature toggles {#filter-feature-toggles}
|
||||
#### Filter feature flags {#filter-feature-toggles}
|
||||
|
||||
Supports three params for now
|
||||
|
||||
@ -87,13 +87,13 @@ To filter for any feature belonging to project `myproject` use
|
||||
|
||||
Response format is the same as `api/client/features`
|
||||
|
||||
### Get specific feature toggle {#get-specific-feature-toggle}
|
||||
### Get specific feature flag {#get-specific-feature-toggle}
|
||||
|
||||
`GET: http://unleash.host.com/api/client/features/:featureName`
|
||||
|
||||
Used to fetch details about a specific feature toggle. This is mainly provided to make it easy to debug the API and should not be used by the client implementations.
|
||||
Used to fetch details about a specific feature flag. This is mainly provided to make it easy to debug the API and should not be used by the client implementations.
|
||||
|
||||
> _Notice_: You will not get a version property when fetching a specific feature toggle by name.
|
||||
> _Notice_: You will not get a version property when fetching a specific feature flag by name.
|
||||
|
||||
```json
|
||||
{
|
||||
@ -163,7 +163,7 @@ In the example `environment` needs to be `production` AND `userId` must be eithe
|
||||
|
||||
### Variants {#variants}
|
||||
|
||||
All feature toggles can also take an array of variants. You can read more about [feature toggle variants](/reference/feature-toggle-variants).
|
||||
All feature flags can also take an array of variants. You can read more about [feature flag variants](/reference/feature-toggle-variants).
|
||||
|
||||
```json
|
||||
{
|
||||
|
||||
@ -17,7 +17,7 @@ Since v4.0.0 all operations require an [API token](/how-to/how-to-create-api-tok
|
||||
|
||||
With versions earlier than v4.0.0 and `insecure` authentication no authentication is required.
|
||||
|
||||
- [Feature Toggles API](./client/features.md)
|
||||
- [Feature Flags API](./client/features.md)
|
||||
- [Register API](./client/register.md)
|
||||
- [Metrics API](./client/metrics.md)
|
||||
|
||||
@ -28,7 +28,7 @@ The internal API used by the Admin UI (unleash-frontend). Since v4.0.0 all opera
|
||||
With versions earlier than v4.0.0 and `insecure` authentication Basic Auth (with curl `-u myemail@test.com:`) is enough.
|
||||
|
||||
- [Events API](./admin/events.md)
|
||||
- [Feature Toggles API](./admin/features.md)
|
||||
- [Feature Flags API](./admin/features.md)
|
||||
- [Metrics API](./admin/metrics.md)
|
||||
- [Project API](./admin/projects.md)
|
||||
- [Strategies API](./admin/strategies.md)
|
||||
|
||||
@ -14,7 +14,7 @@ Note that it's not recommended to expose Prometheus metrics to the public as of
|
||||
|
||||
## Annotations {#annotations}
|
||||
|
||||
Unleash will automatically count all updates for all toggles under the metric name `feature_toggle_update_total`, and the toggle name is will be set as a label value. This information can be used to create annotations in grafana for everytime a feature toggle is changed.
|
||||
Unleash will automatically count all updates for all flags under the metric name `feature_toggle_update_total`, and the flag name is will be set as a label value. This information can be used to create annotations in grafana for everytime a feature flag is changed.
|
||||
|
||||
You can use this query in grafana to achieve this:
|
||||
|
||||
@ -22,4 +22,4 @@ You can use this query in grafana to achieve this:
|
||||
delta(feature_toggle_update_total{toggle="Demo"}[1m]) != bool 0
|
||||
```
|
||||
|
||||
Another useful counter is the `feature_toggle_usage_total` which will give you the numbers for how many times a feature toggle has been evaluated to `active` or not.
|
||||
Another useful counter is the `feature_toggle_usage_total` which will give you the numbers for how many times a feature flag has been evaluated to `active` or not.
|
||||
|
||||
@ -1,36 +1,36 @@
|
||||
---
|
||||
title: Archived Toggles
|
||||
title: Archived Flags
|
||||
---
|
||||
|
||||
You can _archive_ a feature toggle when it is not needed anymore. You do this by clicking the "Archive" button on the feature toggle details view. When you archive a feature toggle, it will no longer be available to Client SDKs.
|
||||
You can _archive_ a feature flag when it is not needed anymore. You do this by clicking the "Archive" button on the feature flag details view. When you archive a feature flag, it will no longer be available to Client SDKs.
|
||||
|
||||
|
||||
|
||||
|
||||
## Viewing archived toggles
|
||||
## Viewing archived flags
|
||||
|
||||
Archived toggles are displayed in two places:
|
||||
Archived flags are displayed in two places:
|
||||
|
||||
1. The global toggle archive
|
||||
2. The containing project's toggle archive
|
||||
1. The global flag archive
|
||||
2. The containing project's flag archive
|
||||
|
||||
Unleash keeps a list of _all_ archived toggles across projects in the _global archive_. The global archive is accessible from the global feature list.
|
||||
Unleash keeps a list of _all_ archived flags across projects in the _global archive_. The global archive is accessible from the global feature list.
|
||||
|
||||
Additionally, each project keeps a list of all of _its_ archived toggles. That is, when you archive a toggle, Unleash adds it to the containing project's archive.
|
||||
Additionally, each project keeps a list of all of _its_ archived flags. That is, when you archive a flag, Unleash adds it to the containing project's archive.
|
||||
|
||||
## Reviving a feature toggle {#reviving-a-feature-toggle}
|
||||
## Reviving a feature flag {#reviving-a-feature-toggle}
|
||||
|
||||
If you want to re-use a feature toggle that you previously archived, you can revive in from the feature toggle archive. Click the "revive icon" to revive the toggle. Revived toggles will be in the disabled state when you re-enable them.
|
||||
If you want to re-use a feature flag that you previously archived, you can revive in from the feature flag archive. Click the "revive icon" to revive the flag. Revived flags will be in the disabled state when you re-enable them.
|
||||
|
||||
|
||||
|
||||
|
||||
## Deleting a feature toggle
|
||||
## Deleting a feature flag
|
||||
|
||||
:::caution
|
||||
|
||||
We generally discourage deleting feature toggles. The reason is that feature toggle names in Unleash are used as identifiers, so if you were to delete a toggle and then create a new one with the same name, the new one would reactivate any code that uses the old toggle.
|
||||
We generally discourage deleting feature flags. The reason is that feature flag names in Unleash are used as identifiers, so if you were to delete a flag and then create a new one with the same name, the new one would reactivate any code that uses the old flag.
|
||||
|
||||
:::
|
||||
|
||||
The only way to fully _delete_ a feature toggle in Unleash is by using the archive. An archived toggle can be deleted via the API or by using the "delete feature toggle" button in the global or project-level archive.
|
||||
The only way to fully _delete_ a feature flag in Unleash is by using the archive. An archived flag can be deleted via the API or by using the "delete feature flag" button in the global or project-level archive.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -20,7 +20,7 @@ Unleash has two types of integrations: Integrations that allow you to listen to
|
||||
|
||||
Unleash currently supports the following integrations out of the box:
|
||||
|
||||
- [Datadog](datadog.md) - Allows Unleash to post Updates to Datadog when a feature toggle is updated.
|
||||
- [Datadog](datadog.md) - Allows Unleash to post Updates to Datadog when a feature flag is updated.
|
||||
- [Jira Cloud](jira-cloud-plugin-usage.md) - Allows you to create, view and manage Unleash feature flags directly from a Jira Cloud issue
|
||||
- [Jira Server](jira-server-plugin-usage.md) - Allows you to create and link Unleash feature flags directly from a Jira Server issue
|
||||
- [Microsoft Teams](teams.md) - Allows Unleash to post updates to Microsoft Teams.
|
||||
|
||||
@ -2,9 +2,9 @@
|
||||
title: Jira Cloud Integration - Usage
|
||||
---
|
||||
|
||||
With the Unleash Jira Cloud Plugin you can create, view and manage Unleash feature toggles directly from a Jira issue.
|
||||
With the Unleash Jira Cloud Plugin you can create, view and manage Unleash feature flags directly from a Jira issue.
|
||||
|
||||
The plugin also shows you current status of connected toggles.
|
||||
The plugin also shows you current status of connected flags.
|
||||
|
||||
## Using the plugin
|
||||
|
||||
@ -12,33 +12,33 @@ To use the plugin, you'll need to create an issue or use an existing one. Once t
|
||||
|
||||
<Figure caption="The Unleash Feature Flags button gets added to the top-level actions of new issues. Use that button to activate the Unleash plugin for that issue." img="/img/jira-cloud-activate-unleash-panel-button.png" />
|
||||
|
||||
### Connecting a toggle to an issue
|
||||
### Connecting a flag to an issue
|
||||
|
||||
<Figure caption="Once active, the Unleash plugin adds a button labeled 'connect toggle' to the issue." img="/img/jira-cloud-issue-button.png" />
|
||||
|
||||
|
||||
Use the issue's "connect toggle" button to open a dialog.
|
||||
|
||||
There are a few steps to connect a toggle:
|
||||
There are a few steps to connect a flag:
|
||||
|
||||
1. Select the Unleash project that contains the toggle:
|
||||
1. Select the Unleash project that contains the flag:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
2. Use the "create new toggle" option to choose whether you want to add an existing toggle or create a new one.
|
||||
2. Use the "create new toggle" option to choose whether you want to add an existing flag or create a new one.
|
||||
|
||||
<Figure caption="When you add an existing toggle, use the toggle name select list to choose from existing toggles in the selected Unleash project." img="/img/jira-cloud-add-existing-toggle.png" />
|
||||
<Figure caption="When you add an existing flag, use the flag name select list to choose from existing flags in the selected Unleash project." img="/img/jira-cloud-add-existing-toggle.png" />
|
||||
|
||||
<Figure caption="When you add a new toggle, you must give it a name and can choose to give it a description." img="/img/jira-cloud-add-new-toggle.png" />
|
||||
<Figure caption="When you add a new flag, you must give it a name and can choose to give it a description." img="/img/jira-cloud-add-new-toggle.png" />
|
||||
|
||||
### Toggle status as part of Issue view
|
||||
### Flag status as part of Issue view
|
||||
|
||||
Once you've connected at least one toggle to an issue, the Unleash plugin will list the current status of each environment for
|
||||
that toggle. If the current user is allowed to edit the issue, they can also enable or disable environments directly
|
||||
Once you've connected at least one flag to an issue, the Unleash plugin will list the current status of each environment for
|
||||
that flag. If the current user is allowed to edit the issue, they can also enable or disable environments directly
|
||||
from Jira.
|
||||
|
||||
<Figure caption="A Jira Cloud issue with a connected toggle. The Unleash feature flags section now shows the connected toggles along with the toggle's environments. There are controls to enable or disable the toggle in the development and production environments" img="/img/jira-cloud-toggle-status.png" />
|
||||
<Figure caption="A Jira Cloud issue with a connected flag. The Unleash feature flags section now shows the connected flags along with the flag's environments. There are controls to enable or disable the flag in the development and production environments" img="/img/jira-cloud-toggle-status.png" />
|
||||
|
||||
### Change Requests
|
||||
|
||||
@ -51,15 +51,15 @@ If you confirm that you would like to open a change request, then the plugin wil
|
||||
|
||||
<Figure caption="A dialog appears when the plugin creates a change request for you. The dialog contains a link directly to the newly created change request." img="/img/jira-cloud-change-request-confirmation.png" />
|
||||
|
||||
When the Change Request has been reviewed and applied in Unleash, the toggle will show the requested state after the next refresh
|
||||
of the issue and toggle status page.
|
||||
When the Change Request has been reviewed and applied in Unleash, the flag will show the requested state after the next refresh
|
||||
of the issue and flag status page.
|
||||
|
||||
|
||||
### Disconnecting toggle from Issue
|
||||
### Disconnecting flag from Issue
|
||||
|
||||
If a toggle is no longer relevant for your Jira Issue, you can disconnect it using the "disconnect toggle" button. This button is only available if your user has edit permissions for the Jira issue.
|
||||
If a flag is no longer relevant for your Jira Issue, you can disconnect it using the "disconnect toggle" button. This button is only available if your user has edit permissions for the Jira issue.
|
||||
|
||||
|
||||
|
||||
|
||||
The toggle will be disconnected immediately. However, the plugin will not delete the toggle from Unleash,
|
||||
so you can still reconnect your Jira issue to the same toggle using the "Connect to existing toggle" functionality
|
||||
The flag will be disconnected immediately. However, the plugin will not delete the flag from Unleash,
|
||||
so you can still reconnect your Jira issue to the same flag using the "Connect to existing flag" functionality
|
||||
|
||||
@ -8,10 +8,10 @@ The Jira Server plugin is **deprecated**, please use the [Unleash Jira Cloud plu
|
||||
|
||||
:::
|
||||
|
||||
With the Unleash Jira server plugin you can create new feature toggles in Unleash from a Jira issue as well as link
|
||||
existing toggles to Jira issues.
|
||||
With the Unleash Jira server plugin you can create new feature flags in Unleash from a Jira issue as well as link
|
||||
existing flags to Jira issues.
|
||||
|
||||
The plugin also shows you current status of connected toggles.
|
||||
The plugin also shows you current status of connected flags.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@ -86,7 +86,7 @@ Since this is a destructive operation, our plugin will ask for confirmation that
|
||||
|
||||
|
||||
|
||||
You cannot delete a server that has toggles connected to issues. Instead, you'll get a
|
||||
warning dialog telling you that you'll need to disconnect the toggles from their issues first.
|
||||
You cannot delete a server that has flags connected to issues. Instead, you'll get a
|
||||
warning dialog telling you that you'll need to disconnect the flags from their issues first.
|
||||
|
||||
|
||||
|
||||
@ -8,46 +8,46 @@ The Jira Server plugin is **deprecated**, please use the [Unleash Jira Cloud plu
|
||||
|
||||
:::
|
||||
|
||||
With the Unleash Jira server plugin you can create new feature toggles in Unleash from a Jira issue as well as link
|
||||
existing toggles to Jira issues.
|
||||
With the Unleash Jira server plugin you can create new feature flags in Unleash from a Jira issue as well as link
|
||||
existing flags to Jira issues.
|
||||
|
||||
The plugin also shows you current status of connected toggles.
|
||||
The plugin also shows you current status of connected flags.
|
||||
|
||||
## Using the plugin
|
||||
|
||||
To use the plugin, you'll need to create an issue or use an existing one. Once the issue is saved and you open up the Issue panel, you'll be greeted with a button to activate the Unleash plugin for that issue.
|
||||
|
||||
### Connecting a toggle to an issue
|
||||
### Connecting a flag to an issue
|
||||
|
||||
|
||||
|
||||
Clicking this button opens a dialog, allowing you to either connect an existing toggle
|
||||
Clicking this button opens a dialog, allowing you to either connect an existing flag
|
||||
|
||||
|
||||
|
||||
|
||||
or if you flip the switch that says "Use existing toggle", allows you to create a new toggle
|
||||
or if you flip the switch that says "Use existing flag", allows you to create a new flag
|
||||
|
||||
|
||||
|
||||
|
||||
### Toggle status as part of Issue view
|
||||
### Flag status as part of Issue view
|
||||
|
||||
Once you've connected at least one toggle to an issue, our plugin will list the current status of each environment for
|
||||
that toggle. If the current user is allowed to edit the issue, they can also enable or disable environments directly
|
||||
Once you've connected at least one flag to an issue, our plugin will list the current status of each environment for
|
||||
that flag. If the current user is allowed to edit the issue, they can also enable or disable environments directly
|
||||
from Jira.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Disconnecting toggle from Issue
|
||||
### Disconnecting flag from Issue
|
||||
|
||||
If a toggle is no longer relevant for your Jira Issue, you can disconnect it using the Disconnect toggle button (
|
||||
If a flag is no longer relevant for your Jira Issue, you can disconnect it using the Disconnect flag button (
|
||||
provided your user has edit rights on the issue)
|
||||
|
||||
|
||||
|
||||
|
||||
Once you click the button, you'll need to confirm the dialog that opens up.
|
||||
|
||||
|
||||
|
||||
|
||||
If confirmed, the toggle will be disconnected immediately. However, the plugin will not delete the toggle from Unleash,
|
||||
so you can still reconnect your Jira issue to the same toggle using the "Connect to existing toggle" functionality
|
||||
If confirmed, the flag will be disconnected immediately. However, the plugin will not delete the flag from Unleash,
|
||||
so you can still reconnect your Jira issue to the same flag using the "Connect to existing flag" functionality
|
||||
|
||||
@ -11,7 +11,7 @@ This Slack integration is deprecated and will be removed in a future release. We
|
||||
|
||||
> This feature was introduced in _Unleash v3.11.0_.
|
||||
|
||||
The Slack integration allows Unleash to post Updates when a feature toggle is updated. To set up Slack, you need to configure an incoming Slack webhook URL. You can follow [Sending messages using Incoming Webhooks](https://api.slack.com/incoming-webhooks) on how to do that. You can also choose to [create a slack app for Unleash](https://api.slack.com/apps), which will provide you with additional functionality to control how Unleash communicates messages on your Slack workspace.
|
||||
The Slack integration allows Unleash to post Updates when a feature flag is updated. To set up Slack, you need to configure an incoming Slack webhook URL. You can follow [Sending messages using Incoming Webhooks](https://api.slack.com/incoming-webhooks) on how to do that. You can also choose to [create a slack app for Unleash](https://api.slack.com/apps), which will provide you with additional functionality to control how Unleash communicates messages on your Slack workspace.
|
||||
|
||||
The Slack integration will perform a single retry if the HTTP POST against the Slack Webhook URL fails (either a 50x or network error). Duplicate events may happen. You should never assume events always comes in order.
|
||||
|
||||
@ -44,7 +44,7 @@ Unleash Slack integration takes the following parameters.
|
||||
- **Slack Webhook URL** - This is the only required property. If you are using a Slack Application you must also make sure your application is allowed to post to the channel you want to post to.
|
||||
- **Username** - Used to override the username used to post the update to a Slack channel.
|
||||
- **Emoji Icon** - Used to override the emoji icon used to post the update to a Slack channel.
|
||||
- **Default channel** - Where to post the message if the feature toggles has not overridden the channel via the slack tags.
|
||||
- **Default channel** - Where to post the message if the feature flags has not overridden the channel via the slack tags.
|
||||
|
||||
#### Global configuration
|
||||
|
||||
@ -52,8 +52,8 @@ Unleash Slack integration takes the following parameters.
|
||||
|
||||
#### Tags {#tags}
|
||||
|
||||
The Slack integration also defined the Tag type "slack". You may use this tag to override which Slack channel Unleash should post updates to for this feature toggle.
|
||||
The Slack integration also defined the Tag type "slack". You may use this tag to override which Slack channel Unleash should post updates to for this feature flag.
|
||||
|
||||
|
||||
|
||||
In the picture you can see we have defined two slack tags for the "new-payment-system" toggle. In this example Unleash will post updates to the **#notifications** and **#random** channel.
|
||||
In the picture you can see we have defined two slack tags for the "new-payment-system" flag. In this example Unleash will post updates to the **#notifications** and **#random** channel.
|
||||
|
||||
@ -5,7 +5,7 @@ title: Microsoft Teams
|
||||
|
||||
> This feature was introduced in _Unleash v4.0.0_.
|
||||
|
||||
The MicrosoftTeams integration allows Unleash to post Updates when a feature toggle is updated. To set up this integration, you need to set up a webhook connector for your channel. You can follow [Creating an Incoming Webhook for a channel](https://docs.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook) on how to do that.
|
||||
The MicrosoftTeams integration allows Unleash to post Updates when a feature flag is updated. To set up this integration, you need to set up a webhook connector for your channel. You can follow [Creating an Incoming Webhook for a channel](https://docs.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook) on how to do that.
|
||||
|
||||
The Microsoft Teams integration will perform a single retry if the HTTP POST against the Microsoft Teams Webhook URL fails (either a 50x or network error). Duplicate events may happen, and you should never assume events always comes in order.
|
||||
|
||||
|
||||
@ -4,7 +4,7 @@ title: SDK overview
|
||||
|
||||
import VideoContent from '@site/src/components/VideoContent.jsx'
|
||||
|
||||
In order to connect your application to Unleash you will need a client SDK (software developer kit) for your programming language and an [API token](../how-to/how-to-create-api-tokens). The SDK will handle connecting to the Unleash server instance and retrieving feature toggles based on your configuration. All versions of Unleash (OSS, Pro, and Enterprise) use the same client SDKs.
|
||||
In order to connect your application to Unleash you will need a client SDK (software developer kit) for your programming language and an [API token](../how-to/how-to-create-api-tokens). The SDK will handle connecting to the Unleash server instance and retrieving feature flags based on your configuration. All versions of Unleash (OSS, Pro, and Enterprise) use the same client SDKs.
|
||||
|
||||
Unleash provides official client SDKs for a number of programming language. Additionally, our community have developed and contributed SDKs for other languages. So if you can't find your favorite language in the list of official SDKs, check out the [list of clients written by our fantastic community](#community-sdks).
|
||||
|
||||
@ -65,9 +65,9 @@ If you see an item marked with a ❌ that you would find useful, feel free to re
|
||||
| Default metrics interval | 60s | 60s | 60s | 60s | 60s | 60s | 30s | 15s |
|
||||
| Context provider | ✅ | N/A | N/A | N/A | N/A | ✅ | ✅ | N/A |
|
||||
| Global fallback function | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
|
||||
| Toggle Query: `namePrefix` | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ |
|
||||
| Toggle Query: `tags` | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ |
|
||||
| Toggle Query: `project_name` | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | N/A | ⭕ |
|
||||
| Flag Query: `namePrefix` | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ |
|
||||
| Flag Query: `tags` | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ |
|
||||
| Flag Query: `project_name` | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | N/A | ⭕ |
|
||||
| **Category: Custom Headers** | | | | | | | | |
|
||||
| static | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ⭕ |
|
||||
| function | ✅ | ✅ | ⭕ | ✅ | ✅ (4.3) | ✅ | ✅ | ⭕ |
|
||||
@ -148,19 +148,19 @@ When the SDK is initialized in the application, an in memory repository is setup
|
||||
|
||||
2. When a page inside the application requests a feature flag, the SDK will return the flag state from memory. No network connection to the frontend API is performed.
|
||||
|
||||
3. The SDK periodically syncs with the frontend API to retrieve the latest set of enabled toggles
|
||||
3. The SDK periodically syncs with the frontend API to retrieve the latest set of enabled flags
|
||||
|
||||
## Working offline
|
||||
|
||||
Once they have been initialized, all Unleash clients will continue to work perfectly well without an internet connection or in the event that the Unleash Server has an outage.
|
||||
|
||||
Because the SDKs and the Unleash Proxy/Edge cache their feature toggle states locally and only communicate with the Unleash server (in the case of the server-side SDKs and the Proxy) or the Proxy/Edge (in the case of front-end SDKs) at predetermined intervals, a broken connection only means that they won't get any new updates.
|
||||
Because the SDKs and the Unleash Proxy/Edge cache their feature flag states locally and only communicate with the Unleash server (in the case of the server-side SDKs and the Proxy) or the Proxy/Edge (in the case of front-end SDKs) at predetermined intervals, a broken connection only means that they won't get any new updates.
|
||||
|
||||
Unless the SDK supports [bootstrapping](#bootstrapping), it _will_ need to connect to Unleash at startup to get its initial feature toggle data set. If the SDK doesn't have a feature toggle data set available, all toggles will fall back to evaluating as disabled or as the specified default value (in SDKs that support that).
|
||||
Unless the SDK supports [bootstrapping](#bootstrapping), it _will_ need to connect to Unleash at startup to get its initial feature flag data set. If the SDK doesn't have a feature flag data set available, all flags will fall back to evaluating as disabled or as the specified default value (in SDKs that support that).
|
||||
|
||||
### Bootstrapping
|
||||
|
||||
By default, all SDKs reach out to the Unleash Server at startup to fetch their toggle configuration. Additionally, some of the server-side SDKs and the Proxy (see the above [compatibility table](#server-side-sdk-compatibility-table)) also support _bootstrapping_, which allows them to get their toggle configuration from a file, the environment, or other local resources. These SDKs can work without any network connection whatsoever.
|
||||
By default, all SDKs reach out to the Unleash Server at startup to fetch their flag configuration. Additionally, some of the server-side SDKs and the Proxy (see the above [compatibility table](#server-side-sdk-compatibility-table)) also support _bootstrapping_, which allows them to get their flag configuration from a file, the environment, or other local resources. These SDKs can work without any network connection whatsoever.
|
||||
|
||||
Bootstrapping is also supported by the following front-end client SDKs:
|
||||
|
||||
|
||||
@ -5,7 +5,7 @@ import VideoContent from '@site/src/components/VideoContent.jsx'
|
||||
|
||||
A/B testing is a type of randomized controlled experiment, where you test two different versions of a feature to see which version performs better. If you have more than two versions, it's known as _multivariate testing_. Coupled with analytics, A/B and multivariate testing enables you to better understand your users and how you can serve them better.
|
||||
|
||||
To facilitate A/B testing and experimentation, Unleash has a built-in 'experiment' [toggle type](../reference/feature-toggle-types.md#feature-toggle-types) and lets you give toggles any number of [variants](../reference/feature-toggle-variants.md). To see a concrete example of configuring multivariate testing with unleash, see [our blog post on A/B testing with Unleash and Google Analytics](https://www.getunleash.io/blog/a-b-n-experiments-in-3-simple-steps).
|
||||
To facilitate A/B testing and experimentation, Unleash has a built-in 'experiment' [flag type](../reference/feature-toggle-types.md#feature-toggle-types) and lets you give flags any number of [variants](../reference/feature-toggle-variants.md). To see a concrete example of configuring multivariate testing with unleash, see [our blog post on A/B testing with Unleash and Google Analytics](https://www.getunleash.io/blog/a-b-n-experiments-in-3-simple-steps).
|
||||
|
||||
In the rest of this document, _A/B testing_ will refer to both strict A/B testing and multivariate testing unless otherwise specified.
|
||||
|
||||
@ -44,20 +44,20 @@ Don't do yourself a disservice by chasing one metric above all else. Keep an eye
|
||||
|
||||
## A/B testing with Unleash
|
||||
|
||||
Feature toggles are a great way to run A/B tests and to decouple them from your code, and Unleash ships with features to make it easy to get started with.
|
||||
Feature flags are a great way to run A/B tests and to decouple them from your code, and Unleash ships with features to make it easy to get started with.
|
||||
|
||||
Toggles can be used for different purposes and we consider experimentation important enough to have given it its own [toggle type](../reference/feature-toggle-types.md#feature-toggle-types). Experiment toggles have a lifetime expectancy suited to let you run an experiment and gather enough data to know whether it was a success or not.
|
||||
Flags can be used for different purposes and we consider experimentation important enough to have given it its own [flag type](../reference/feature-toggle-types.md#feature-toggle-types). Experiment flags have a lifetime expectancy suited to let you run an experiment and gather enough data to know whether it was a success or not.
|
||||
|
||||
If you're running a basic A/B test where the control group doesn't see any change, then a basic experiment toggle will do the job excellently. With a [gradual rollout](../reference/activation-strategies#gradual-rollout), some appropriate [strategy constraints](../reference/strategy-constraints.md), and an analytics tool of your choosing, you should be all set to start collecting metrics and measuring.
|
||||
If you're running a basic A/B test where the control group doesn't see any change, then a basic experiment flag will do the job excellently. With a [gradual rollout](../reference/activation-strategies#gradual-rollout), some appropriate [strategy constraints](../reference/strategy-constraints.md), and an analytics tool of your choosing, you should be all set to start collecting metrics and measuring.
|
||||
|
||||
If you want to run a more advanced experiment, then take a look at using [feature toggle variants](../reference/feature-toggle-variants). If you have a control group, and want to test multiple potential improvements, then simply add your desired variants to the toggle as discussed in the previous paragraph. If you want to launch a new feature (or a headline) in multiple variations right out the gate, consider using a basic on/off toggle with variants and activate it for all your users.
|
||||
If you want to run a more advanced experiment, then take a look at using [feature flag variants](../reference/feature-toggle-variants). If you have a control group, and want to test multiple potential improvements, then simply add your desired variants to the flag as discussed in the previous paragraph. If you want to launch a new feature (or a headline) in multiple variations right out the gate, consider using a basic on/off flag with variants and activate it for all your users.
|
||||
|
||||
### Impression data
|
||||
|
||||
[Impression data](../reference/impression-data.md) is an Unleash feature that was released in Unleash 4.7.
|
||||
It allows you to capture events whenever a feature toggle is checked in your applications.
|
||||
The event contains all the information about the toggle and the current context, so you can pass everything onto your third-party analytics provider, such as [Google Analytics](https://analytics.google.com/analytics) or [Posthog](https://posthog.com/).
|
||||
This makes Unleash even more useful as an A/B testing tool and makes it much easier to correlate events and variants with feature toggles and Unleash context.
|
||||
It allows you to capture events whenever a feature flag is checked in your applications.
|
||||
The event contains all the information about the flag and the current context, so you can pass everything onto your third-party analytics provider, such as [Google Analytics](https://analytics.google.com/analytics) or [Posthog](https://posthog.com/).
|
||||
This makes Unleash even more useful as an A/B testing tool and makes it much easier to correlate events and variants with feature flags and Unleash context.
|
||||
|
||||
|
||||
## Summary
|
||||
|
||||
@ -10,7 +10,7 @@ Allowing engineers, product owners, and even technical support to have open acce
|
||||
|
||||
2. **Visibility into Configuration**:
|
||||
|
||||
- **Configuration Transparency**: Engineers, product owners, and even technical support should be able to view the feature toggle configuration. This transparency provides insights into which features are currently active, what conditions trigger them, and how they impact the application's behavior. It helps understand the system's state and behavior, which is crucial for making informed decisions.
|
||||
- **Configuration Transparency**: Engineers, product owners, and even technical support should be able to view the feature flag configuration. This transparency provides insights into which features are currently active, what conditions trigger them, and how they impact the application's behavior. It helps understand the system's state and behavior, which is crucial for making informed decisions.
|
||||
|
||||
- **Change History**: Access to a history of changes made to feature flags, including who made the changes and when, is invaluable. This audit trail allows teams to track changes to the system's behavior over time. It aids in accountability and can be instrumental in troubleshooting when unexpected behavior arises after a change.
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: 11 Principles for building and scaling feature flag systems
|
||||
---
|
||||
|
||||
Feature flags, sometimes called feature toggles or feature switches, are a software development technique that allows engineering teams to decouple the release of new functionality from software deployments. With feature flags, developers can turn specific features or code segments on or off at runtime, without the need for a code deployment or rollback. Organizations who adopt feature flags see improvements in all key operational metrics for DevOps: Lead time to changes, mean-time-to-recovery, deployment frequency, and change failure rate.
|
||||
Feature flags, sometimes called feature flags or feature switches, are a software development technique that allows engineering teams to decouple the release of new functionality from software deployments. With feature flags, developers can turn specific features or code segments on or off at runtime, without the need for a code deployment or rollback. Organizations who adopt feature flags see improvements in all key operational metrics for DevOps: Lead time to changes, mean-time-to-recovery, deployment frequency, and change failure rate.
|
||||
|
||||
There are 11 principles for building a large-scale feature flag system. These principles have their roots in distributed systems architecture and pay particular attention to security, privacy, and scale that is required by most enterprise systems. If you follow these principles, your feature flag system is less likely to break under load and will be easier to evolve and maintain.
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
title: Unleash introductory overview
|
||||
---
|
||||
|
||||
One of the most important aspects of the architecture to understand is that feature toggles are evaluated in client SDKs which runs as part of your application. This makes toggle evaluations super-fast (_we're talking nano-seconds_), scalable and resilient against network disturbances. In order to achieve this Unleash incurs a small update-delay when you change your toggle configurations until it is fully propagated to your application (in terms of seconds and is configurable).
|
||||
One of the most important aspects of the architecture to understand is that feature flags are evaluated in client SDKs which runs as part of your application. This makes flag evaluations super-fast (_we're talking nano-seconds_), scalable and resilient against network disturbances. In order to achieve this Unleash incurs a small update-delay when you change your flag configurations until it is fully propagated to your application (in terms of seconds and is configurable).
|
||||
|
||||
If you want more details you can read about [our unique architecture](https://www.getunleash.io/blog/our-unique-architecture).
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user