diff --git a/CHANGELOG.md b/CHANGELOG.md index 650bd6c772..200cf5c990 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,7 +1,7 @@ # Changelog ## 2.1.0 -- Provide a set of defined activation strategies: +- Provide a set of pre-defined activation strategies: - applicationHostname - gradualRolloutRandom - gradualRolloutSessionId diff --git a/docs/activation-strategies.md b/docs/activation-strategies.md index 1e54c53ab6..5f486d49a3 100644 --- a/docs/activation-strategies.md +++ b/docs/activation-strategies.md @@ -16,27 +16,39 @@ Active for users with a userId defined in the userIds-list. Typically I want to - userIds - *List of user ids you want the feature toggle should be enabled for* ## gradualRolloutUserId -Gradually activate feature toggle for logged in users. Stickiness based on user id. ers. This strategy guarantees that the same user gets the same experience every time, across devices. It also guarantees that a user which is among the first 10% will also be among 20% roll-out degree. Thus we ensures that users gets the same experience, even if we gradually increase the number of users we expose the feature to. To achieve this we use a clever hash-algorithm where we normalize the user-id to a number between 1 and 100. +Gradually activate feature toggle for logged in users. Stickiness based on user id. +This strategy guarantees that the same user gets the same experience every time, +across devices. It also guarantees that a user which is among the first 10% will also +be among 20% roll-out degree. Thus we ensure that users gets the same experience, +even if we gradually increase the number of users we expose the feature to. To +achieve this we use a hash-algorithm where we normalize the user-id to a number +between 1 and 100. **Parameters** - percentage - *The percentage (0-100) you want to enable to feature toggle for.* - groupId - *Used to define a activation groups, which allows you to correlate across feature toggles.* ## gradualRolloutSessionId -Gradually activate feature toggle. Stickiness based on session id. It is almost identical to the gradualRolloutUserId-strategy, with the exception that it works on 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. But might get different experience in different sessions. +Gradually activate feature toggle. Stickiness based on session id. It is almost +identical to the `gradualRolloutUserId` strategy, with the exception that it works +on 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** - percentage - *The percentage (0-100) you want to enable to feature toggle for.* - groupId - *Used to define a activation groups, which allows you to correlate across feature toggles.* ## gradualRolloutRandom -Randomly activate the feature toggle. No stickiness. We have found this rollout strategy very useful in some scenarios, especially when we are enabling a feature which is not visible to the user. It is also the strategy we use to sample metrics and error reports. +Randomly activate the feature toggle. No stickiness. We have found this rollout strategy +very useful in some scenarios, especially when we are enabling a feature which is not +visible to the user. It is also the strategy we use to sample metrics and error reports. **Parameters** - percentage - *The percentage (0-100) you want to enable to feature toggle for.* ## remoteAddress -Active for remote addresses defined in the IPs list. We sometimes use this strategy to enable a feature only for IP's in our office network. +Active for remote addresses defined in the IPs list. We sometimes use this strategy to +enable a feature only for IP's in our office network. **Parameters** - IPS - *List of IPs to enable the feature for.* diff --git a/docs/unleash-context.md b/docs/unleash-context.md index 0f9276d6b4..03367f84e0 100644 --- a/docs/unleash-context.md +++ b/docs/unleash-context.md @@ -1,6 +1,6 @@ # Unleash Context -In order to standardize a few activation strategies we also needed to +In order to standardise a few activation strategies we also needed to standardize a unleash context, which contains some fields that varies per requests, needed to implement the activation strategies. @@ -19,4 +19,4 @@ E.g. the userWithId-strategy obviously depends on the userId field. The properties field is more generic and can be used to probide more abritary data to the strategies. A common usage is to add more metadata, e.g. that the current user is a beta user, and thus the betaUser-strategy will use this info -in it's implementation. +in its implementation. diff --git a/migrations/20170211085502-built-in-strategies.js b/migrations/20170211085502-built-in-strategies.js index e28a36a7c7..e1f6586acf 100644 --- a/migrations/20170211085502-built-in-strategies.js +++ b/migrations/20170211085502-built-in-strategies.js @@ -1,4 +1,3 @@ -/* eslint camelcase: "off" */ 'use strict'; const async = require('async'); diff --git a/migrations/20170211090541-add-default-strategies.js b/migrations/20170211090541-add-default-strategies.js index b0d91ad0df..fad8fe0968 100644 --- a/migrations/20170211090541-add-default-strategies.js +++ b/migrations/20170211090541-add-default-strategies.js @@ -1,4 +1,3 @@ -/* eslint camelcase: "off" */ 'use strict'; const strategies = require('./default-strategies.json');