Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Category Vision - Feature Flags

Feature Flags

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 native support for feature flags directly into your development and delivery process.

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.

What's Next & Why

Now that we have released feature flags that support two different strategies, % rollout gitlab-ee#8240 and userID gitlab-ee#11459, we are moving forward with using feature flags internally as part of our deployment process gitlab-ce#57943.

Another important feature that we are actively working on is the ability to control the permissions for feature flags for protected environments gitlab-ce#8239.

Maturity Plan

This category is currently at the "Viable" maturity level, and our next maturity target is Complete (see our definitions of maturity levels). Key deliverables to achieve this are:

Competitive Landscape

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] (https://gitlab.com/gitlab-org/gitlab-ee/issues/13308)

There is a detailed LaunchDarkly comparison from when the project was first being conceived here.

Analyst Landscape

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-ee#9450 introduces new in-product documentation to help development and operations teams learn how to successfully adopt feature flags.

Top Customer Success/Sales Issue(s)

None yet, but feedback is welcome.

Top Customer Issue(s)

Being able to manage feature flags from an environment view gitlab-ee#9098

Top Internal Customer Issue(s)

Delivery Team

Top Vision Item(s)

Our top vision item is to help people get started with feature flags. See the analyst section above for additional details.