The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Feature Flags, a.k.a. Feature Toggle, allows the application development team to control access to code across different environments. It is an effective way to decouple deployment from the delivery or release of the software feature.
Feature flags is also a key safety measure when deploying software. Rather than rolling back and re-deploying, you can simply turn on or off a problematic change. As such Feature flag is a linchpin for our progressive delivery strategy; it allows for many small incremental versions of software to be simultaneously delivered without the cost of constant branching, merging and deploying code.
GitLab is a complete and connected Feature Flag solution.
GitLab Feature Flags enables you to set up feature flags for your applications and services, including server-side and client-side instrumentation with complete language support and unlimited scalability. GitLab Feature Flags provides you with the flexibility and control you need to target the exact audience you want.
GitLab Feature Flags is also a connected capability in your DevOps platform, integrated intelligently from planning issues all the way to observability data. As a decision-maker setting up a feature flag or rolling out changes, you have full information and can even automate feature flag updates without manual intervention.
Lastly, GitLab Feature Flags supports your specific operating model. You can choose to self-manage your Feature Flag solution or have GitLab manage a globally available, SaaS feature flag solution. GitLab Feature Flags does not need to be managed in the same fashion as the rest of your DevOps platform.
The GitLab Feature Flag 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 can introduce technical debt when applied improperly. For example, feature flags can be forgotten and left as stale code.
The feature flags product category is currently in maintenance mode. We do not have any new features on our roadmap.
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 will be driving new requirements to the base features that are out there already, 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, we expect that our primary adopters of this feature will be pre-existing GitLab users looking for incremental value. For buyers who are considering replacing other tools, and looking for something that integrates feature flags with issues, we will 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.
A competitor review of LaunchDarkly can be found in gitlab&4102. 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.
Our top customer success issue, and one that comes up frequently in customer calls is gitlab#8239 which talks about feature flag permissions. This will explicitly give permissions to toggle feature flags on/off based on the environment.
Our top customer issue is gitlab#206666 which captures changes in feature flag strategy in an audit log. This will help in terms of compliance and in investigating historical feature flag changes.
Being able to link feature flags to issues via gitlab#220333 is our most active internal customer issue. This gives users full context of when a feature is hidden behing a feature flag and allows direct access to the flag from the issue to allow managing it's strategies, environemnts and status.
Our Fulfilment team has been actively dogfooding our feature flags and have requested the ability to warn users before removing an environment from a feature flag, which will in fact, disable the feature flag via 285127 and a way to easily locate feature flags from anywhere in the GitLab tool using quick search via gitlab#285130.
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.