このページの情報は古くなっている可能性があります。 最新の情報は 本家サイト でご確認ください。
Feature Flags can be used as part of software development to enable a feature to be tested even before it is completed and ready for release. A feature flag is used to enable or disable the feature during run time. The unfinished features are hidden (toggled) so they do not appear in the user interface.
Tying into our progressive delivery strategy, this allows many small incremental versions of software to be delivered without the cost of constant branching and merging.
Our ultimate goal is to provide an easy way to configure and monitor feature flags that integrate into the continuous development cycle. Visual ties from feature flags to ongoing issues and merge requests will help understand the state and exposure of each feature and a comprehensive dashboard will allow developers to take action when necessary in order to minimize risk and technical debt.
Feature Flags is built with an Unleash-compatible API, ensuring interoperability with any other compatible tooling, and taking advantage of the various client libraries available for Unleash. Unleash have recently announced that they are spinning up a hosted (paid) option while maintaining their open source offering. We will be monitoring this closely.
While Feature flags are a great tool for incremental delivery, they also introduce technical debt, sometimes feature flags are forgotten and left as stale code.
In the last few milestones, we worked on revising the architecture of Feature flags to support multiple strategies per environment. With gitlab#35571 we'll enable you to view this new strategy information in the feature flag dashboard.
Additionally, we are replacing the "percent rollout strategy" with "flexible rollout" via gitlab#36380. In order to provide more control over your rollouts, this will add the ability to define the stickiness of the rollout based on session ID, user ID, or to be random (no stickiness).
This category is currently at the "Viable" maturity level, and our next maturity target is Complete (see our definitions of maturity levels).
Our focus at the moment is on using the feature internally to deliver GitLab itself. This is driving new requirements to the base features that are out there, and also helping us to ensure the list for complete maturity is accurate. Our plan is for our feature flag solution to compete with other products on the market such as LaunchDarkly or Rollout. As we work towards complete maturity, our expectation is that our primary adopters of this feature will be pre-existing GitLab users looking for incremental value. For buyers who are considering replacing JIRA, and looking for something that integrates feature flags with issues, we can also provide a valuable solution as we head towards complete maturity.
Key deliverables to achieve this are:
Other feature flag products offer more comprehensive targeting and configuration. The simplicity of our solution is actually a strength compared to this in some cases, but there is some basic functionality still to add. As we are rigorously working to close the gaps with the competitors, our next strategy to tackle will be the ability to configure feature flags based on groups gitlab-ee#13308
There is a detailed LaunchDarkly comparison from when the project was first being conceived here.
We are conducting a renewed competitor review of LaunchDarkly in gitlab#197727. If you have additional insights or are interested in joining in the conversation, please comment on the issue.
Analysts are recognizing that this sort of capability is becoming more a part of what's fundamentally needed for a continuous delivery platform, in order to minimize blast radius from changes. Often, solutions in this space are complex and hard to get up and running with, and they are not typically bundled or well integrated with CD solutions.
This backs up our desire to not over complicated the solution space here, and highlights the need for guidance. gitlab#9450 introduces new in-product documentation to help development and operations teams learn how to successfully adopt feature flags.
Since GitLab serves as a single application tool, users who use our feature flags and issue management, can associate feature flags directly from the issue and vice versa and view the current deployment status via (gitlab#26456).
This will provide visibility from the issue itself, and will let you know which feature flag is associated with it, its status, and percent rollout from the feature flag view, enabling you control and insights from wherever you wish to manage your feature flags.
Our most popular customer issue is to open-source Feature Flags via gitlab#212318.
Adding a webhook for feature flag events via gitlab#220898 to trigger pipeline actions and even email/slack notifications in case a flag was toggled. This can be really useful for automation, and to help keep you informed on the feature flag status at all times.
We have completed the re-architecture of Feature Flags, adding the ability to support multiple strategies per environment via API and UI (gitlab#204895. Our Fulfillment, Expansion, and Telemetry teams have joined the dogfooding effort for this. The feedback from this process is being tracked in gitlab&3760.
One of our main themes in CI/CD is Progressive delivery. Feature flags, by definition, are a form of progressive delivery as they allow you to deploy code incrementally and control the audience that will receive the new code. Our top vision issues are connecting Feature Flags to issues, Merge Requests, and Epics so that our users can benefit from our single application toolchain. This will enable users to better understand the context of a feature flag and their state to the associated plan, release, and deployment.