Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: flexibleRollout as a built-in strategy #516

Closed
ivarconr opened this issue Oct 23, 2019 · 0 comments · Fixed by #517
Closed

feat: flexibleRollout as a built-in strategy #516

ivarconr opened this issue Oct 23, 2019 · 0 comments · Fixed by #517

Comments

@ivarconr
Copy link
Member

ivarconr commented Oct 23, 2019

See specification

Flexible Rollout Strategy - SDK Development Guide

Flexible Rollout Strategy is pretty similar to the existing rollout strategies (gradualRolloutRandom, gradualRolloutSessionId, gradualRolloutUserId). It differs in that it combines all of them into one and allow the user to select how the rollout-stickiness should work, with a default behaviour which uses the available data on the context.

image

Technical details

  • Client-specification tests
  • Unleash UI demo. - Connect your client SDK using these details:
    • Client API: https://eu.unleash-hosted.com/demo/api/
    • Authorization header: 56907a2fa53c1d16101d509a10b78e36190b0f918d9f122d

Protocol

{
    "createdAt": "2019-08-02T19:25:13.976Z", 
    "description": "Play with strategy constraints", 
    "enabled": true, 
    "name": "Demo", 
    "strategies": [
        {
            "constraints": [], 
            "name": "flexibleRollout", 
            "parameters": {
                "groupId": "Demo", 
                "rollout": 100, 
                "stickiness": "default"
            }
        }
    ]
}

Parameters for the **flexibleRollout strategy:

  • 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:
    • 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 behaviour would be false
    • **SESSIONID - **guaranteed to be sticky on sessionId. If sessionId not present the behaviour would be false.
    • RANDOM - no stickiness guaranteed. For every isEnabled call it will yield a random true/false based on the selected rollout percentage.
  • groupId is used to ensure that different toggles will hash differently for the same user. The groupId defaults to feature toggle name, but is overridable by the user to correlate rollout of multiple feature toggles.
  • rollout The percentage (0-100) you want to enable the feature toggle for.

(this is breaking out of #442)

ivarconr pushed a commit that referenced this issue Oct 23, 2019
ivarconr pushed a commit to Unleash/unleash-frontend that referenced this issue Oct 24, 2019
ivarconr added a commit to Unleash/unleash-frontend that referenced this issue Oct 24, 2019
ivarconr added a commit to Unleash/unleash-frontend that referenced this issue Oct 24, 2019
ivarconr added a commit that referenced this issue Oct 24, 2019
* feat: Add new Flexible Rollout Strategy

fixes #516

* feat: update unleash-frontend to version 3.2.8

* chore: update flexible rollout documentation
ivarconr added a commit that referenced this issue Feb 20, 2020
* feat: Add new Flexible Rollout Strategy

fixes #516

* feat: update unleash-frontend to version 3.2.8

* chore: update flexible rollout documentation
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant