Minimal Unleash Client for GitLab.com
Description
This is a first step towards completing #26842 (closed). See also #26842 (comment 307106527).
Instantiate the Unleash client and configure it to pull feature flags from our chosen GitLab instance. Use our existing Flipper-based feature flags to control this so we can turn the Unleash client off and on for gitlab.com
. Ideally, we would be able to turn it off completely with a feature flag so that it stops making HTTP requests.
Make up a very simple feature that we would like to be able to toggle off and on for gitlab.com
with no intention of shipping to self-managed instances. Maybe change the color of a button or something similarly trivial. Or perhaps we could find a simple change we would actually like to get feedback on. Use the configured Unleash client (perhaps wrapped in our own code) to turn it on or off based on user id with a userWithId
strategy.
This is probably going to require careful configuration of the Unleash client: https://github.com/Unleash/unleash-client-ruby#list-of-arguments
Logging is probably something we want to setup properly at this point, or at least it needs to be considered.
We also need to establish where feature flags for gitlab.com
will live. It sounded like we might use ops.gitlab.net
for this, but we have to figure that out.
Hopefully we don't need more caching at this point than what the Unleash client already provides. This estimate assumes we don't, but we probably have to think about it at this point and decide if that holds up or not.
We have already added configuration values for the Unleash client:
We may need to add more.
We also have the Unleash gem installed: https://gitlab.com/gitlab-org/gitlab/-/blob/97daf04e38677c5cd0ed82b03f562b90dc2a1212/Gemfile#L471
The Unleash gem probably needs to be upgraded.
Proposal
- Document the Feature Flag in the DB so that it can easily be toggled by anyone.
- Make up a very simple feature that we would like to be able to toggle off and on for
gitlab.com
- TBD - Disable the Feature for self-managed instances.
- Use the configured Unleash client (perhaps wrapped in our own code) to turn it on or off based on user id with a
userWithId
strategy. - userID should be all member of the Progressive Delivery group - only we should see the feature and other should not - Collect Unleash Metrics (for logging purposes)