Make flag rollout a first class feature

[markphelps]

Is your feature request related to a problem? Please describe.

It's currently possible to do a flag rollout (enabling a flag for x% of requests) by using a combination of Segments and Variants, however its not very intuitive.

Ex:

1. Creating a flag with variants 'on' and 'off'
2. Creating a rule to return 'on' for 50% of users in an empty segment
3. Update your client code to check for 'on' or 'off'

You can then change the value from 50% -> 100% over time to 'rollout' the feature to all users

Describe the solution you'd like

This isnt very intuitive. It would be great if there was a simple slider on the flag or targeting page to allow this same functionality without having to create placeholder variants and then update the distributions

Additional context Add any other context or screenshots about the feature request here.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[pietdaniel]

Some thoughts on this manner. When rolling out features there are a few patterns I find desirable:

• A % of hosts | containers | processes in a deterministic manner so that if a host receives multiple requests it has the the same behavior. With large deployments rolling out to the same 2 machines is helpful in debugging subtle errors in new code paths
• A % of tenants for the application to some definition of tenant (user, organization, customer, etc)
• A % of requests on each hosts | containers | processes, so that each one will dispatch in a similar means

Often times feature flags are useful for "testing in prod" and if a new codepath hard crashes a process, you want to restrict the blast zone to a subset of processes or a subset of tenants. Having all processes crash 50% of the time can be dangerous.

[markphelps]

FYI this is currently in progress 🎉 . We plan to roll out a new set of evaluation endpoints under a new /evaluation/v1/ path so that we don't disrupt the current evaluation endpoints.

This may also allow us to fix #1351 at the same time if we come up with a configuration that makes sense to allow enabling/disabling auth for the new routes