Feature Flags should be read from repository
Problem to solve
Currently all our GitLab Feature Flags are very UI-centric. This is good for managing just a few feature flags, but fails when managing many feature flags, like we have for GitLab.
We should import feature flags from YAML definition into UI and tie the FF lifecycle with YAML. It seems that we have general agreement on how we want to manage YAML-based feature flags definitions. It would be great if GitLab Feature Flags would read and prefill the UI. This way we significantly reduce the burden of using UI to add all feature flags (as they are still controlled by developers), and make it easy to SRE and other people to manage what is in fact part of deployment.
Consider, this becomes pretty awesome then:
- We have our environment/deployments
- We make GitLab Feature Flags to be in-sync with YAML definitions
- GitLab Feature Flags can detect if the FF is part of the deployed change,
- GitLab FF can also read and store default status of FF as soon as it sees new change
This is based on premise:
- Developers prefers file-based workflow / GitOps: as it makes it easier to manage many
- Product prefers UI-based workflow: as it is easier to see what is ON and where
This could be considered reverse dog fooding: instead of introducing a product into development, we would introduce a change in our engineering practices that would be dogfooded by our product (GitLab Feature Flags).
Proposal
Read and populate GitLab Feature Flags
from a directory where each feature flag is in a individual YAML file,
as proposed in !31610 (closed).
We would still retain an ability to control Feature Flags via UI using CRUD interface. This would only focus on allowing us to manage Create/Delete
aspect of Feature Flags with YAML definitions. This would build on existing implementation of Feature Flags as an additional way to populate database of available feature flags and theirs default.
Links / references
As part of dog-fooding the change being introduced by:
- !31610 (closed) we could follow that definition proposed and read it into GitLab Feature Flags
- https://gitlab.com/gitlab-org/labkit-ruby/-/issues/12: allows us to unify the handling across the whole stack
- gitlab-com/www-gitlab-com#7048 (comment 341704564): we significantly go above what and how the Unleash offers and what other Feature Flags system can offer on market: deep integration with codebase
- !31610 (comment 345942009): cross link for what definition is proposed
- !32311 (merged)