mirror of
https://github.com/Unleash/unleash.git
synced 2024-12-22 19:07:54 +01:00
chore: Fix documentation typos (#758)
Co-authored-by: Alexis Degrugillier <alexis.degrugillier@duproprio.com>
This commit is contained in:
Alexis Degrugillier
GitHub
parent
efe6507263
commit
0f60fd075a
@ -43,7 +43,7 @@ By enabling the stickiness option on a custom context field you can use it toget
|
||||
|
||||
## gradualRolloutUserId
|
||||
|
||||
The `gradualRolloutUserId` strategy gradually activates a feature toggle for logged in users. Stickiness is based on the user ID. The strategy guarantees that the same user gets the same experience every time across devices. It also assures that a user which is among the first 10% will also be among the first 20% of the users. That way, we ensure the users get the same experience, even if we gradually increase the number of users exposed to a particular feature. To achieve this, we hash the user ID and normalize the hash value to a number between 1 and 100 with a simple modulo operator.
|
||||
The `gradualRolloutUserId` strategy gradually activates a feature toggle for logged-in users. Stickiness is based on the user ID. The strategy guarantees that the same user gets the same experience every time across devices. It also assures that a user which is among the first 10% will also be among the first 20% of the users. That way, we ensure the users get the same experience, even if we gradually increase the number of users exposed to a particular feature. To achieve this, we hash the user ID and normalize the hash value to a number between 1 and 100 with a simple modulo operator.
|
||||
|
||||
|
||||
|
||||
@ -56,7 +56,7 @@ Starting from v3.x all clients should use the 32-bit [MurmurHash3](https://en.wi
|
||||
|
||||
## gradualRolloutSessionId
|
||||
|
||||
Similar to `gradualRolloutUserId` strategy, this strategy gradually activates a feature toggle, with the exception being that the stickiness is based on the session IDs. This makes it possible to target all users (not just logged in users), guaranteeing that a user will get the same experience within a session.
|
||||
Similar to `gradualRolloutUserId` strategy, this strategy gradually activates a feature toggle, with the exception being that the stickiness is based on the session IDs. This makes it possible to target all users (not just logged-in users), guaranteeing that a user will get the same experience within a session.
|
||||
|
||||
**Parameters**
|
||||
|
||||
|
||||
@ -5,7 +5,7 @@ title: Addons Introduction
|
||||
|
||||
> This feature was introduced in _Unleash v3.11.0_.
|
||||
|
||||
Unleash Addons allows you to extend Unleash with new functionality. Currently addons allow you to listen to changes in Unleash and trigger updates in other systems, typical via a WebHook.
|
||||
Unleash Addons allows you to extend Unleash with new functionality. Currently, addons allow you to listen to changes in Unleash and trigger updates in other systems, typical via a WebHook.
|
||||
|
||||
Currently Unleash support the following Addons out of the box:
|
||||
|
||||
|
||||
@ -27,13 +27,13 @@ You can choose to trigger updates for the following events (we might add more ev
|
||||
Unleash Slack addon 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 overriden the channel via the slack tags.
|
||||
- **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.
|
||||
|
||||
#### Tags
|
||||
|
||||
The Slack addon 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 addon 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.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -30,7 +30,7 @@ Unleash Webhook addon takes the following parameters.
|
||||
|
||||
**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 the channel you want to post to.
|
||||
|
||||
**Content-Type** Used to set the content-type header used when unleash performs a HTTP POST to the defined endpoint.
|
||||
**Content-Type** Used to set the content-type header used when unleash performs an HTTP POST to the defined endpoint.
|
||||
|
||||
**Body template** Used to override the body template used by Unleash when performing the HTTP POST. You may format you message using a [Mustache template](https://mustache.github.io). You will have the [Unleash event format](/docs/api/admin/events) available in the rendering context.
|
||||
|
||||
|
||||
@ -4,15 +4,15 @@ title: API Access
|
||||
---
|
||||
|
||||
> **Enterprise**
|
||||
> This guide is only relevant if your are using Unleash-hosted.
|
||||
> This guide is only relevant if you are using Unleash-hosted.
|
||||
|
||||
It is possible to integrate directly with the Admin API. In this guide we will explain all the steps to set it up.
|
||||
|
||||
## Step 1: Create API token
|
||||
|
||||
You will need access tokens with admin privileges to be allowed to connect to the Admin Unleash-API. You can create these tokens in the “Instance Admin” as part of the “API secrets” section.
|
||||
You will need access tokens with admin privileges to be allowed to connect to the Admin Unleash-API. You can create these tokens in the “Instance Admin” as part of the “API secrets” section.
|
||||
|
||||
Please note that it may take up to 60 seconds for the new key to propagate to all Unleash-hosted instances.
|
||||
Please note that it may take up to 60 seconds for the new key to propagate to all Unleash-hosted instances.
|
||||
|
||||
> If you need an API token to use in a client SDK you should create a "client token" as these have less access.
|
||||
|
||||
|
||||
@ -14,7 +14,7 @@ Feature toggle types currently supported by Unleash:
|
||||
- **Release** - Used to enable trunk-based development for teams practicing Continuous Delivery. _Expected lifetime 40 days_
|
||||
- **Experiment** - Used to perform multivariate or A/B testing. _Expected lifetime 40 days_
|
||||
- **Operational** - Used to control operational aspects of the system's behavior. _Expected lifetime 7 days_
|
||||
- **Kill switch** - Used to to gracefully degrade system functionality. _(permanent)_
|
||||
- **Kill switch** - Used to gracefully degrade system functionality. _(permanent)_
|
||||
- **Permission** - Used to change the features or product experience that certain users receive. _(permanent)_
|
||||
|
||||
### Deprecate a feature toggle
|
||||
|
||||
@ -7,17 +7,17 @@ title: Strategy Constraints
|
||||
>
|
||||
> Strategy constraints is only available with the Unleash-hosted offering and is not part of Unleash Open-Source.
|
||||
|
||||
Strategy constraints allow you to set pre-conditions on activation strategies that needs to be satisfied for the activation strategies to take effect.
|
||||
Strategy constraints allow you to set pre-conditions on activation strategies that needs to be satisfied for the activation strategies to take effect.
|
||||
|
||||
## Constrain on a specific environment
|
||||
|
||||
The most common use case for strategy constraints is that you want an activation strategy to only take effect in a specific environment. For example you could enable the feature for everyone in development, while you only expose the new feature to a few percentage of users in production.
|
||||
The most common use case for strategy constraints is that you want an activation strategy to only take effect in a specific environment. For example, you could enable the feature for everyone in development, while you only expose the new feature to a few percent of users in production.
|
||||
|
||||
|
||||
|
||||
## Constrain on custom context fields
|
||||
|
||||
It is also possible to constrain a activation strategy configuration on custom context fields. A common use case is a multi-tenant service where you want to control roll-out on a tenant identifier. This allows you to decide which customer should get access to your new feature.
|
||||
It is also possible to constrain an activation strategy configuration on custom context fields. A common use case is a multi-tenant service where you want to control roll-out on a tenant identifier. This allows you to decide which customer should get access to your new feature.
|
||||
|
||||
|
||||
|
||||
@ -32,7 +32,7 @@ You can also define your own custom context fields that you can use together wit
|
||||
- customerType
|
||||
- tenantId
|
||||
|
||||
Combining strategy constraints with the “flexibleRollout” allows you to do gradual roll-out to a specific segment of your user base.
|
||||
Combining strategy constraints with the “flexibleRollout” allows you to do a gradual roll-out to a specific segment of your user base.
|
||||
|
||||
### Step 1: Navigate to “Context Fields“
|
||||
Locate “context fields in the menu
|
||||
@ -41,7 +41,7 @@ Locate “context fields in the menu
|
||||
|
||||
### Step 2: Define new context field
|
||||
|
||||
Next you can define your new context field. The minimum requirement is to give it a unique *name*. In addition you can give it a description and define the legal values.
|
||||
Next you can define your new context field. The minimum requirement is to give it a unique *name*. In addition, you can give it a description and define the legal values.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -21,6 +21,6 @@ When adding a new tag, a dropdown will show you which type of tag you're about t
|
||||
|
||||
Types can be anything, and their purpose is to add some semantics to the tag itself.
|
||||
|
||||
Some tag types will be defined by plugins (e.g. the slack plugin can define the slack-type, to make it easy to specify which slack channels to post updates for a specific feature toggle to).
|
||||
Some tag types will be defined by plugins (e.g. the slack plugin can define the Slack-type, to make it easy to specify which Slack channels to post updates for a specific feature toggle to).
|
||||
|
||||
Other tags can be defined by the user to give semantic logic to the management of the UI. It could be that you want to use tag functionality to specify which products a feature toggle belongs to, or to which teams.
|
||||
|
||||
@ -3,7 +3,7 @@ id: events
|
||||
title: /api/admin/events
|
||||
---
|
||||
|
||||
> In order to access the admin api endpoints you need to identify yourself. If you are using the `unsecure` authententication method, you may use [basic authenticaion](https://en.wikipedia.org/wiki/Basic_access_authentication) to ientify yourself.
|
||||
> In order to access the admin api endpoints you need to identify yourself. If you are using the `unsecure` authentication method, you may use [basic authentication](https://en.wikipedia.org/wiki/Basic_access_authentication) to identify yourself.
|
||||
|
||||
# Events API
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ id: features
|
||||
title: /api/admin/features
|
||||
---
|
||||
|
||||
> In order to access the admin api endpoints you need to identify yourself. If you are using the `unsecure` authententication method, you may use [basic authenticaion](https://en.wikipedia.org/wiki/Basic_access_authentication) to ientify yourself.
|
||||
> In order to access the admin api endpoints you need to identify yourself. If you are using the `unsecure` authentication method, you may use [basic authentication](https://en.wikipedia.org/wiki/Basic_access_authentication) to identify yourself.
|
||||
|
||||
### Fetching Feature Toggles
|
||||
|
||||
@ -146,7 +146,7 @@ Used by the admin-dashboard to create a new feature toggles.
|
||||
- _name_ **must be globally unique**, otherwise you will get a _403-response_.
|
||||
- _type_ is optional. If not defined it defaults to `release`
|
||||
|
||||
Returns 200-respose if the feature toggle was created successfully.
|
||||
Returns 200-response if the feature toggle was created successfully.
|
||||
|
||||
### Update a Feature Toggle
|
||||
|
||||
@ -173,7 +173,7 @@ Returns 200-respose if the feature toggle was created successfully.
|
||||
|
||||
Used by the admin dashboard to update a feature toggles. The name has to match an existing features toggle.
|
||||
|
||||
Returns 200-respose if the feature toggle was updated successfully.
|
||||
Returns 200-response if the feature toggle was updated successfully.
|
||||
|
||||
### Tag a Feature Toggle
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ id: feature-types
|
||||
title: /api/admin/feature-types
|
||||
---
|
||||
|
||||
> In order to access the admin api endpoints you need to identify yourself. If you are using the `unsecure` authententication method, you may use [basic authenticaion](https://en.wikipedia.org/wiki/Basic_access_authentication) to ientify yourself.
|
||||
> In order to access the admin api endpoints you need to identify yourself. If you are using the `unsecure` authentication method, you may use [basic authentication](https://en.wikipedia.org/wiki/Basic_access_authentication) to identify yourself.
|
||||
|
||||
# Feature Types API
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ id: metrics
|
||||
title: /api/admin/metrics
|
||||
---
|
||||
|
||||
> In order to access the admin api endpoints you need to identify yourself. If you are using the `unsecure` authententication method, you may use [basic authenticaion](https://en.wikipedia.org/wiki/Basic_access_authentication) to ientify yourself.
|
||||
> In order to access the admin api endpoints you need to identify yourself. If you are using the `unsecure` authentication method, you may use [basic authentication](https://en.wikipedia.org/wiki/Basic_access_authentication) to identify yourself.
|
||||
|
||||
# This document describes the metrics endpoint for admin ui
|
||||
|
||||
@ -40,7 +40,7 @@ This enpoints returns a list of applications and what toogles unleash has seen f
|
||||
|
||||
`GET http://unleash.host.com/api/admin/metrics/feature-toggles`
|
||||
|
||||
This endpoint gives _last minute_ and _last hour_ metrics for all active toggles. This is based on metrics reported by client applications. Yes is the number of times a given feature toggle was evaluated to enabled in a client applcation, and no is the number it avaluated to false.
|
||||
This endpoint gives _last minute_ and _last hour_ metrics for all active toggles. This is based on metrics reported by client applications. Yes is the number of times a given feature toggle was evaluated to enabled in a client application, and no is the number it was evaluated to false.
|
||||
|
||||
**Example response:**
|
||||
|
||||
@ -80,13 +80,13 @@ This endpoint gives _last minute_ and _last hour_ metrics for all active toggles
|
||||
**Fields:**
|
||||
|
||||
- **lastHour** - Hour projection collected metrics for all feature toggles.
|
||||
- **lastMinute** - Mintue projection collected metrics for all feature toggles.
|
||||
- **lastMinute** - Minute projection collected metrics for all feature toggles.
|
||||
|
||||
### Applications
|
||||
|
||||
`GET http://unleash.host.com/api/admin/applications`
|
||||
|
||||
This endpoint returns a list of known applications (seen the last two days) and a link to follow for more datails.
|
||||
This endpoint returns a list of known applications (seen the last two days) and a link to follow for more details.
|
||||
|
||||
```json
|
||||
{
|
||||
@ -121,7 +121,7 @@ You can also specify the query param: _strategyName_, which will return all appl
|
||||
|
||||
`GET http://unleash.host.com/api/admin/applications/:appName`
|
||||
|
||||
This endpoint gives insight into details about a client applcation, such as instances, strategies implemented and seen toogles.
|
||||
This endpoint gives insight into details about a client application, such as instances, strategies implemented and seen toggles.
|
||||
|
||||
```json
|
||||
{
|
||||
|
||||
@ -3,14 +3,14 @@ id: state
|
||||
title: /api/admin/state
|
||||
---
|
||||
|
||||
> In order to access the admin api endpoints you need to identify yourself. If you are using the `unsecure` authententication method, you may use [basic authenticaion](https://en.wikipedia.org/wiki/Basic_access_authentication) to ientify yourself.
|
||||
> In order to access the admin api endpoints you need to identify yourself. If you are using the `unsecure` authentication method, you may use [basic authentication](https://en.wikipedia.org/wiki/Basic_access_authentication) to identify yourself.
|
||||
|
||||
### Export Feature Toggles & Strategies
|
||||
|
||||
`GET: http://unleash.host.com/api/admin/state/export`
|
||||
|
||||
The api endpoint `/api/admin/state/export` will export feature-toggles and strategies as json by default.\
|
||||
You can customize the export with queryparameters:
|
||||
You can customize the export with query parameters:
|
||||
|
||||
| Parameter | Default | Description |
|
||||
| --- | --- | --- |
|
||||
@ -67,10 +67,10 @@ You can either send the data as JSON in the POST-body or send a `file` parameter
|
||||
|
||||
**Query Paramters**
|
||||
|
||||
- **drop** - Use this paramter if you want the database to be cleaned before import (all strategies and features will be removed).
|
||||
- **keep** - Use this query parameter if you want keep all exiting feature toggle (and strategy) configurations as is (no override), and only insert missing feature toggles from the data provided.
|
||||
- **drop** - Use this parameter if you want the database to be cleaned before import (all strategies and features will be removed).
|
||||
- **keep** - Use this query parameter if you want to keep all exiting feature toggle (and strategy) configurations as is (no override), and only insert missing feature toggles from the data provided.
|
||||
|
||||
> You should be careful useing the `drop` parameter in production environments.
|
||||
> You should be careful using the `drop` parameter in production environments.
|
||||
|
||||
Success: `202 Accepted`\
|
||||
Error: `400 Bad Request`
|
||||
|
||||
@ -3,13 +3,13 @@ id: strategies
|
||||
title: /api/admin/strategies
|
||||
---
|
||||
|
||||
> In order to access the admin api endpoints you need to identify yourself. If you are using the `unsecure` authententication method, you may use [basic authenticaion](https://en.wikipedia.org/wiki/Basic_access_authentication) to ientify yourself.
|
||||
> In order to access the admin api endpoints you need to identify yourself. If you are using the `unsecure` authentication method, you may use [basic authentication](https://en.wikipedia.org/wiki/Basic_access_authentication) to identify yourself.
|
||||
|
||||
### Fetch Strategies
|
||||
|
||||
`GET: http://unleash.host.com/api/admin/strategies`
|
||||
|
||||
Used to fetch all defined strategies and their defined paramters.
|
||||
Used to fetch all defined strategies and their defined parameters.
|
||||
|
||||
**Response**
|
||||
|
||||
@ -112,7 +112,7 @@ Used to create a new Strategy. Name is required and must be unique. It is also r
|
||||
},
|
||||
```
|
||||
|
||||
Used to update a Strategy definition. Name can't be changed. **PS! I can be dangerous to change a implemnted strategy as the implementation also might need to be changed**
|
||||
Used to update a Strategy definition. Name can't be changed. **PS! I can be dangerous to change an implemented strategy as the implementation also might need to be changed**
|
||||
|
||||
### Deprecate strategy
|
||||
|
||||
@ -128,8 +128,8 @@ _404 NOT FOUND_ - if `:name` does not exist
|
||||
|
||||
`POST: https://unleash.host.com/api/admin/strategies/:name/reactivate`
|
||||
|
||||
Used to reactivate a deprecated strategy defintion. This will set the deprecated flag back to false. If the strategy is not deprecated this is a noop and will still return 200.
|
||||
Used to reactivate a deprecated strategy definition. This will set the deprecated flag back to false. If the strategy is not deprecated this is a noop and will still return 200.
|
||||
|
||||
#### Errors
|
||||
|
||||
_404 NOT FOUND_ - if if `:name` does not exist
|
||||
_404 NOT FOUND_ - if `:name` does not exist
|
||||
|
||||
@ -121,7 +121,7 @@ Used to fetch all types the server knows about. This endpoint is the one all adm
|
||||
|
||||
`GET: https://unleash.host.com/api/admin/tag-types/simple`
|
||||
|
||||
Used to fetch details about a specific tag-type. This is mostly provded to make it easy to debug the API and should not be used by the client implementations.
|
||||
Used to fetch details about a specific tag-type. This is mostly provided to make it easy to debug the API and should not be used by the client implementations.
|
||||
|
||||
**Example response:**
|
||||
|
||||
|
||||
@ -159,7 +159,7 @@ In the example `environment` needs to be `production` AND `userId` must be eithe
|
||||
- **values** - is a list of values (string).
|
||||
- **operator** - is the logical action to take on the values Supported operator are:
|
||||
- **IN** - constraint is satisfied if one of the values in the list matches the value for this context field in the context.
|
||||
- **NOT_IN** - constrint is satisfied if NONE of the values is the list matches the value for this field in the context.
|
||||
- **NOT_IN** - constraint is satisfied if NONE of the values is the list matches the value for this field in the context.
|
||||
|
||||
### Variants
|
||||
|
||||
|
||||
@ -21,4 +21,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 time 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 toggle has been evaluated to `active` or not.
|
||||
|
||||
@ -3,8 +3,8 @@ id: open_api
|
||||
title: Open API Specification
|
||||
---
|
||||
|
||||
> The Unleash Open API Specifications are still considered a beta functionality. We have (for now) manually written all the specifications for all API endpoints. We are testing this functinality, and the ultimate goal will be to auto-generate these specifications from the code itself.
|
||||
> The Unleash Open API Specifications are still considered a beta functionality. We have (for now) manually written all the specifications for all API endpoints. We are testing this functionality, and the ultimate goal will be to auto-generate these specifications from the code itself.
|
||||
|
||||
The Open API Specifcation is hosted as part of the online demo: http://unleash.herokuapp.com/oas/
|
||||
The Open API Specification is hosted as part of the online demo: http://unleash.herokuapp.com/oas/
|
||||
|
||||
You can also allow your own Unleash instance to serve the Open API specification by setting the `ENABLE_OAS` environment variable to true: `ENABLE_OAS=true`
|
||||
|
||||
@ -9,7 +9,7 @@ This document attempts to guide developers in implementing an Unleash Client SDK
|
||||
|
||||
## System Overview
|
||||
|
||||
Unleash is comprised of three parts:
|
||||
Unleash is composed of three parts:
|
||||
|
||||
- **Unleash API** - The service holding all feature toggles and their configurations. Configurations declare which activation strategies to use and which parameters they should get.
|
||||
- **Unleash UI** - The dashboard used to manage feature toggles, define new strategies, look at metrics, etc.
|
||||
@ -98,7 +98,7 @@ Unleash also ships with a few built-in strategies, and expects client SDK's to i
|
||||
|
||||
### Extension points
|
||||
|
||||
Client implementation should also provide a defined interface to make it easier for the user to implement their own activation strategies, and register those in the unleash client.
|
||||
Client implementation should also provide a defined interface to make it easier for the user to implement their own activation strategies, and register those in the Unleash client.
|
||||
|
||||
## Fetching feature toggles (polling)
|
||||
|
||||
|
||||
@ -111,7 +111,7 @@ function googleAdminAuth(app) {
|
||||
}
|
||||
```
|
||||
|
||||
Implement a preRouter hook for `/api/admin/login`. It's neccesary for login with Google.
|
||||
Implement a preRouter hook for `/api/admin/login`. It's necessary for login with Google.
|
||||
|
||||
```js
|
||||
function googleAdminAuth(app) {
|
||||
|
||||
@ -32,12 +32,12 @@ 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 also possible to not override exiting feature toggles (and strategies) by using the `keepExisting` parameter.
|
||||
It is also possible to not override exiting feature toggles (and strategies) by using the `keepExisting` parameter.
|
||||
|
||||
### API Export
|
||||
|
||||
The api endpoint `/api/admin/state/export` will export feature-toggles and strategies as json by default.\
|
||||
You can customize the export with queryparameters:
|
||||
You can customize the export with query parameters:
|
||||
|
||||
| Parameter | Default | Description |
|
||||
| --- | --- | --- |
|
||||
|
||||
@ -15,7 +15,7 @@ After upgrading all your clients, you should consider turning off legacy routes,
|
||||
|
||||
## Upgrading from v1.0 to v2.0
|
||||
|
||||
### Caveat 1: Not used db-migrate to migrate the unleash database?
|
||||
### Caveat 1: Not used db-migrate to migrate the Unleash database?
|
||||
|
||||
In FINN we used liquibase, for internal reasons, to migrate our database.
|
||||
Because unleash from version 2.0 migrates the database internally, with db-migrate, you need to make sure that all previous migrations for version 1 exist, so that Unleash does not try to create already existing tables.
|
||||
|
||||
@ -7,7 +7,7 @@ title: Developer guide
|
||||
|
||||
To run and develop unleash, you need to have PostgreSQL database (PostgreSQL v10.x or newer) locally.
|
||||
|
||||
> Unleash currently also work with PostgreSQL v9.5+, but this might change in a future feature relase, and we have stopped runnig automatic integration tests below PostgreSQL v10.
|
||||
> Unleash currently also work with PostgreSQL v9.5+, but this might change in a future feature release, and we have stopped running automatic integration tests below PostgreSQL v10.
|
||||
|
||||
### Create a local unleash databases in postgres
|
||||
|
||||
|
||||
@ -84,4 +84,4 @@ unleash.IsEnabled("someToggle", context);
|
||||
|
||||
b) Via a UnleashContextProvider
|
||||
|
||||
This is a bit more advanced approach, where you configure a unleash-context provider. By doing this you do not have rebuild or pass the unleash-context object to every place you are calling unleash.IsEnabled. You can read more, and get [examples about this option on GitHub](https://github.com/Unleash/unleash-client-dotnet#unleashcontextprovider).
|
||||
This is a bit more advanced approach, where you configure an unleash-context provider. By doing this, you do not have to rebuild or to pass the unleash-context object to every place you are calling `unleash.IsEnabled`. You can read more, and get [examples about this option on GitHub](https://github.com/Unleash/unleash-client-dotnet#unleashcontextprovider).
|
||||
|
||||
@ -14,7 +14,7 @@ In this guide we explain how to use feature toggles in a Java application using
|
||||
>You can find this information in your “Instance admin” available in your Unleash management UI.
|
||||
|
||||
|
||||
## Step 1: Install client SDK
|
||||
## Step 1: Install the client SDK
|
||||
|
||||
First we must add Unleash Client SDK as a dependency to your project. Below is an example of how you would add it to your pom.xml in Java:
|
||||
|
||||
@ -28,7 +28,7 @@ First we must add Unleash Client SDK as a dependency to your project. Below is a
|
||||
|
||||
## Step 2: Create a new Unleash Instance
|
||||
|
||||
Next must must initialize a new instance of the Unleash Client.
|
||||
Next we must initialize a new instance of the Unleash Client.
|
||||
|
||||
```java
|
||||
UnleashConfig unleashConfig = UnleashConfig.builder()
|
||||
@ -83,7 +83,7 @@ unleash.isEnabled("someToggle", context);
|
||||
|
||||
**b) Via a UnleashContextProvider**
|
||||
|
||||
This is a bit more advanced approach, where you configure a unleash-context provider. By doing this you do not have rebuild or pass the unleash-context object to every place you are calling unleash.isEnabled.
|
||||
This is a bit more advanced approach, where you configure a unleash-context provider. By doing this you do not have to rebuild or to pass the unleash-context object to every place you are calling `unleash.isEnabled`.
|
||||
|
||||
The provider typically binds the context to the same thread as the request. If you are using Spring the UnleashContextProvider will typically be a ‘request scoped’ bean.
|
||||
|
||||
|
||||
@ -13,7 +13,7 @@ In this guide we explain how to use feature toggles in a Node application using
|
||||
>- **API Secret** – Your API secret required to connect to your instance.
|
||||
>You can find this information in your “Instance admin” available in your Unleash management UI.
|
||||
|
||||
## Step 1: Install client SDK
|
||||
## Step 1: Install the client SDK
|
||||
|
||||
First we must install Node.js dependency:
|
||||
|
||||
@ -21,7 +21,7 @@ First we must install Node.js dependency:
|
||||
npm install unleash-client --save
|
||||
```
|
||||
|
||||
## Step 2: Initialize client SDK
|
||||
## Step 2: Initialize the client SDK
|
||||
|
||||
Next we must initialize the client SDK in the application:
|
||||
|
||||
|
||||
@ -18,4 +18,4 @@ All fields are optional, but if they are not set you will not be able to use cer
|
||||
|
||||
E.g., the `userWithId` strategy obviously depends on the `userId` field.
|
||||
|
||||
The `properties` field is more generic and can be used to provide more abritary data to strategies. Typical usage is to add more metadata. For instance, the `betaUser` strategy may read a field from `properties` to check whether the current user is a beta user.
|
||||
The `properties` field is more generic and can be used to provide more arbitrary data to strategies. Typical usage is to add more metadata. For instance, the `betaUser` strategy may read a field from `properties` to check whether the current user is a beta user.
|
||||
|
||||
@ -15,7 +15,7 @@ It is the simplest activation strategy and basically means "active for everyone"
|
||||
|
||||
## userWithId
|
||||
|
||||
Active for users with a `userId` defined in the `userIds` list. Typically I want to enable a new feature only for myself in production before I enable it for everyone else. To achieve this, we can use the “UserWithIdStrategy”. This strategy allows you to specify a list of user IDs that you want to expose the new feature for. (A user id may, of course, be an email if that is more appropriate in your system.)
|
||||
Active for users with a `userId` defined in the `userIds` list. Typically, I want to enable a new feature only for myself in production before I enable it for everyone else. To achieve this, we can use the “UserWithIdStrategy”. This strategy allows you to specify a list of user IDs that you want to expose the new feature for. (A user id may, of course, be an email if that is more appropriate in your system.)
|
||||
|
||||
**Parameters**
|
||||
|
||||
@ -23,11 +23,11 @@ Active for users with a `userId` defined in the `userIds` list. Typically I want
|
||||
|
||||
## flexibleRollout
|
||||
|
||||
A flexible rollout strategy which combines all gradual rollout strategies in to a single strategy (and will in time replace them). This strategy have different options for how you want to handle the stickiness, and have sane default mode.
|
||||
A flexible rollout strategy which combines all gradual rollout strategies in to a single strategy (and will in time replace them). This strategy has different options for how you want to handle the stickiness, and have sane default mode.
|
||||
|
||||
**Parameters**
|
||||
|
||||
- **stickiness** is used to define how we guarantee consistency for gradual rollout. The same userId and the same rollout percentage should give predictable results. Configuration that should be supported:
|
||||
- **stickiness** is used to define how we guarantee consistency for a gradual rollout. The same userId and the same rollout percentage should give predictable results. Configuration that should be supported:
|
||||
- **default** - Unleash chooses the first value present on the context in defined order userId, sessionId, random.
|
||||
- **userId** - guaranteed to be sticky on userId. If userId not present the behavior would be false
|
||||
- **sessionId** - guaranteed to be sticky on sessionId. If sessionId not present the behavior would be false.
|
||||
@ -44,7 +44,7 @@ NB! this feature is currently only supported by the following SDKs:
|
||||
|
||||
## gradualRolloutUserId
|
||||
|
||||
The `gradualRolloutUserId` strategy gradually activates a feature toggle for logged in users. Stickiness is based on the user ID. The strategy guarantees that the same user gets the same experience every time across devices. It also assures that a user which is among the first 10% will also be among the first 20% of the users. That way, we ensure the users get the same experience, even if we gradually increase the number of users exposed to a particular feature. To achieve this, we hash the user ID and normalize the hash value to a number between 1 and 100 with a simple modulo operator.
|
||||
The `gradualRolloutUserId` strategy gradually activates a feature toggle for logged-in users. Stickiness is based on the user ID. The strategy guarantees that the same user gets the same experience every time across devices. It also assures that a user which is among the first 10% will also be among the first 20% of the users. That way, we ensure the users get the same experience, even if we gradually increase the number of users exposed to a particular feature. To achieve this, we hash the user ID and normalize the hash value to a number between 1 and 100 with a simple modulo operator.
|
||||
|
||||
|
||||
|
||||
@ -57,7 +57,7 @@ Starting from v3.x all clients should use the 32-bit [MurmurHash3](https://en.wi
|
||||
|
||||
## gradualRolloutSessionId
|
||||
|
||||
Similar to `gradualRolloutUserId` strategy, this strategy gradually activates a feature toggle, with the exception being that the stickiness is based on the session IDs. This makes it possible to target all users (not just logged in users), guaranteeing that a user will get the same experience within a session.
|
||||
Similar to `gradualRolloutUserId` strategy, this strategy gradually activates a feature toggle, with the exception being that the stickiness is based on the session IDs. This makes it possible to target all users (not just logged-in users), guaranteeing that a user will get the same experience within a session.
|
||||
|
||||
**Parameters**
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ id: connect_sdk
|
||||
title: Connect your SDK
|
||||
---
|
||||
|
||||
In order to connect your application to Unleash you need to use a client SDK (software developer kit) for your programming language. The SDK will handle connecting to the unleash server instance and retrieve feature toggles based upon your configuration. Both open source and the unleash enterprise offering utilize the same set of client SDKs.
|
||||
In order to connect your application to Unleash you need to use a client SDK (software developer kit) for your programming language. The SDK will handle connecting to the Unleash server instance and retrieve feature toggles based upon your configuration. Both open-source and the Unleash enterprise offering utilize the same set of client SDKs.
|
||||
|
||||
If you are an Unleash customer, our hosted instances will always be a protected instance, you will therefore have to specify a client secret as the authorization header when you are connecting your client SDK, which you will receive from us when you sign up for one of our packages. In the open source version you must generate your own secret.
|
||||
|
||||
|
||||
@ -11,7 +11,7 @@ In this guide you will learn how to control the roll-out (expose it to real user
|
||||
|
||||
Unleash comes with a few common activation strategies. Some of them require the client to provide the unleash-context, which gives the necessary context for Unleash.
|
||||
|
||||
The built in activation strategies:
|
||||
The built-in activation strategies:
|
||||
|
||||
- default
|
||||
- userWithId
|
||||
@ -27,7 +27,7 @@ When you create a new feature toggle you will get the default activation strateg
|
||||
|
||||
## The userWithId strategy
|
||||
|
||||
When we have deployed some new code to production it would be nice to enable the new feature for ourselves before we enable it to everyone else. To achieve this in Unleash you can use the **userWithId** activation strategy. This strategy allows you to specify a list of user IDs that you want to expose the new feature for.
|
||||
When we have deployed some new code to production it would be nice to enable the new feature for ourselves before we enable it to everyone else. To achieve this with Unleash, you can use the **userWithId** activation strategy. This strategy allows you to specify a list of user IDs that you want to expose the new feature for.
|
||||
|
||||
A userId is how you identify users in your system (email, UUID, etc) and is provided as part of the Unleash Context to the client SDK.
|
||||
|
||||
@ -39,7 +39,7 @@ In order to increase the exposure of the feature which is protected with the fea
|
||||
|
||||
|
||||
|
||||
In the example above we have configure two activation strategies, **userWithId** and **flexibleRollout**. If one of them evaluates to true the feature toggle is considered enabled. In the example we have enabled the feature toggle for usersWithId (*me@mail.com and another@mail.com*) in addition to 10% of the traffic.
|
||||
In the example above we have to configure two activation strategies, **userWithId** and **flexibleRollout**. If one of them evaluates to true the feature toggle is considered enabled. In the example we have enabled the feature toggle for usersWithId (*me@mail.com and another@mail.com*) in addition to 10% of the traffic.
|
||||
|
||||
## Summary
|
||||
|
||||
|
||||
@ -32,7 +32,7 @@ The toggle is now created and ready to be used. The toggle does not have any met
|
||||
|
||||
## Step 4: Enable the feature toggle only for your boss!
|
||||
|
||||
The next step is to change the activation strategy to only target your boss. You can use the “userWithId”-strategy for that. Using the configuration shown below will only enable the feature toggle for “boss@company.com” and “me@company.com”. Thus you can safely test your feature in production, without exposing it to your users. In [control roll-out](./control_rollout) with strategies we will go in to greater details on how to use activation strategies to gradually expose new features to your users.
|
||||
The next step is to change the activation strategy to only target your boss. You can use the “userWithId”-strategy for that. Using the configuration shown below will only enable the feature toggle for “boss@company.com” and “me@company.com”. Thus, you can safely test your feature in production, without exposing it to your users. In [control roll-out](./control_rollout) with strategies we will go in to greater details on how to use activation strategies to gradually expose new features to your users.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -3,4 +3,4 @@ id: discover_unkonwn_toggles
|
||||
title: Discover unknown toggles
|
||||
---
|
||||
|
||||
Discover unkonwn toggles
|
||||
Discover unknown toggles
|
||||
|
||||
@ -21,7 +21,7 @@ Before you can connect your application to Unleash you need a Unleash server. Yo
|
||||
|
||||
## System Overview
|
||||
|
||||
Unleash is comprised of three parts:
|
||||
Unleash is composed of three parts:
|
||||
|
||||
- **Unleash API** - The service holding all feature toggles and their configurations. Configurations declare which activation strategies to use and which parameters they should get.
|
||||
- **Unleash UI** - The dashboard used to manage feature toggles, define new strategies, look at metrics, etc.
|
||||
@ -29,4 +29,4 @@ Unleash is comprised of three parts:
|
||||
|
||||
|
||||
|
||||
To be super fast (*we talk nano-seconds*), the client SDK caches all feature toggles and their current configuration in memory. The activation strategies are also implemented in the SDK. This makes it really fast to check if a toggle is on or off because it is just a simple function operating on local state, without the need to poll data from the database.
|
||||
To be super fast (*we talk nano-seconds*), the client SDK caches all feature toggles and their current configuration in memory. The activation strategies are also implemented in the SDK. This makes it really fast to check if a toggle is on or off because it is just a simple function operating on local state, without the need to poll data from the database.
|
||||
|
||||
@ -5,7 +5,7 @@ title: Working with native apps
|
||||
|
||||
> **Enterprise feature**
|
||||
>
|
||||
> Working with native apps, require the unleash proxy. The Unleash Proxy is only available with the Unleash-hosted offering and is not part of Unleash Open-Source.
|
||||
> Working with native apps, require the Unleash proxy. The Unleash Proxy is only available with the Unleash-hosted offering and is not part of Unleash Open-Source.
|
||||
|
||||
For a highlevel introduction to the Unleash-proxy, please read this short article [The Unleash-Proxy](https://www.unleash-hosted.com/articles/the-unleash-proxy)
|
||||
|
||||
@ -15,7 +15,7 @@ The Unleash-proxy consist of the proxy that exposes a simple API for the client.
|
||||
|
||||
## The Proxy-client
|
||||
|
||||
There is a js implentation of the proxy-client available.
|
||||
There is a js implementation of the proxy-client available.
|
||||
Find it here: [https://github.com/unleash-hosted/unleash-proxy-client-js](https://github.com/unleash-hosted/unleash-proxy-client-js)
|
||||
|
||||
## The Proxy-API
|
||||
|
||||
@ -18,4 +18,4 @@ All fields are optional, but if they are not set you will not be able to use cer
|
||||
|
||||
E.g., the `userWithId` strategy obviously depends on the `userId` field.
|
||||
|
||||
The `properties` field is more generic and can be used to provide more abritary data to strategies. Typical usage is to add more metadata. For instance, the `betaUser` strategy may read a field from `properties` to check whether the current user is a beta user.
|
||||
The `properties` field is more generic and can be used to provide more arbitrary data to strategies. Typical usage is to add more metadata. For instance, the `betaUser` strategy may read a field from `properties` to check whether the current user is a beta user.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user