A feature flag is a technique in SW development that enables a feature to be tested even before it is completed and ready for release. Feature flag is used to hide, enable or disable the feature during run time. The technique allows developers to release a version of a product that has unfinished features. These unfinished features are hidden (toggled) so they do not appear in the user interface. This allows many small incremental versions of software to be delivered without the cost of constant branching and merging.
Feature flags unlock faster, more agile delivery workflows by providing control over the flexibility of deployment to a specific environment or audience. In addition it reduces risk to production, in case a problem is detected, disabling the feature is as easy as turning off a switch.
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.
Interested in joining the conversation for this category? Please join us in our public epic where we discuss this topic and can answer any questions you may have. Your contributions are more than welcome.
Now that we have released feature flags that support two different strategies, % rollout (gitlab#8240) and userID (gitlab#11459), we are moving forward with using feature flags internally as part of our deployment process (gitlab#26842).
In addition, we are working on a powerful integration between feature flags and the issues and/or merge requests that are affected by them. Since GitLab serves as a single application tool, users can now associate feature flags directly form the issue or merge request and vice versa and view the current deployment status from any location (gitlab#26456).
This category is currently at the "Viable" maturity level, and our next maturity target is Complete (see our definitions of maturity levels).
We currently have basic capabilities and want to continue and extend these in the upcoming releases.
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.
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. It's also unclear how to get started.
This backs up our desire to not overcomplicated 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.
None yet, but feedback is welcome.
Being able to manage feature flags from an environment view gitlab#9098
Our top vision item is to Natively support hypercloud deployments, we want to help make it easier and quicker to get started and deploy to any one of the big cloud providers using GitLab's CI/CD..