Userid-based access for Feature Flags
Problem to solve
We recently rolled out feature flags with the ability to turn a feature off or on. Another important capability of feature flags is to be able to set a list where, for users who have the userid(s) named, they will always see the feature in question enabled in any environment. Turning this on will allow very targeted testing using Feature Flags, and will supplement Review Apps nicely as a way to validate that changes deployed to production are working without having to jump through hoops to review them.
This is part of the Progressive Delivery MVC (&1198), specifically the
stage 1 section that's about enabling developers to do controlled rollouts.
The Unleash client library already supports userid-based scenarios (https://github.com/Unleash/unleash/blob/master/docs/activation-strategies.md#userwithid), which sets the feature flags based on the logged in user of the remote system (i.e., not the GitLab user). This is useful in the early stages that the feature is still under evaluation, when you want for example all of your internal employees and/or beta users to access the feature. For the access, they have to register their (non-GitLab) user ID to a feature flag at first. Usually, beta users (i.e. external users) don't have direct access to a feature flag control panel so they have to contact to the company or internal employee first to be added.
- Update our implementation of the server API to support associating a userid with a feature flag
- Display the associated userids in the Feature Flag UI
- Allow adding/removing userids in the UI.
Users & Security
Because the userIDs in play are the non-GitLab users, we have limited visibility into what those might be. This is a good thing, we don't want to start pulling potentially personally identifying information into GitLab and we also don't want to bring GitLab security considerations around user management into play here.
UserID selection is based on simple string matching, as you can see how it works if you use the Unleash UI here:
The Unleash API does not support pattern matching like
*@example.com via this functionality, so we need to ensure this interface allows for pasting lists of users into it rather than requiring lots of individual clicking to add and remove people.
Specifying explicit userIDs that will have a feature enabled is more specific than a general rule that the feature flag is off, or that it is doing a 50% rollout - therefore, if a userID rule is set then it will take precedence over other rules. This follows the behavior of the Unleash API but should be clear to users.
These new userID change events must be added to the already in-place auditing system for feature flags as well.
What does success look like, and how can we measure that?
- number of times someone modified the user id list for feature flags in a project
- need to do analysis of current feature engagement with feature flags to determine target number for engagement metric above
- don't know yet how much we expect this to drive, but it should be significant enough to drive MAU for Release towards the 8% improvement in concert with #8240, which enables % rollout.