- Risks when enabling features still in development
- Risks when disabling released features
- How to enable and disable features behind flags
GitLab adopted feature flags strategies to deploy features in an early stage of development so that they can be incrementally rolled out.
Before making them permanently available, features can be deployed behind flags for a number of reasons, such as:
- To test the feature.
- To get feedback from users and customers while in an early stage of the development of the feature.
- To evaluate users adoption.
- To evaluate how it impacts the performance of GitLab.
- To build it in smaller pieces throughout releases.
Features behind flags can be gradually rolled out, typically:
- The feature starts disabled by default.
- The feature becomes enabled by default.
- The feature flag is removed.
These features can be enabled and disabled to allow or disallow users to use them. It can be done by GitLab administrators with access to GitLab Rails console.
When you disable a feature flag, the feature is hidden from users and all of the functionality is turned off. For example, data is not recorded and services do not run.
If you used a certain feature and identified a bug, a misbehavior, or an error, it’s very important that you provide feedback to GitLab as soon as possible so we can improve or fix it while behind a flag. When you upgrade GitLab to an earlier version, the feature flag status may change.
Features that are disabled by default may change or be removed without notice in a future version of GitLab.
Data corruption, stability degradation, performance degradation, or security issues might occur if you enable a feature that’s disabled by default. Problems caused by using a default disabled feature aren’t covered by GitLab support, unless you were directed by GitLab to enable the feature.
Security issues found in features that are disabled by default are patched in regular releases and do not follow our regular maintenance policy with regards to backporting the fix.
In most cases, the feature flag code is removed in a future version of GitLab. If and when that occurs, from that point onward you can’t keep the feature in a disabled state.
Each feature has its own flag that should be used to enable and disable it. The documentation of each feature behind a flag includes a section informing the status of the flag and the command to enable or disable it.
The first thing you need to enable or disable a feature behind a flag is to start a session on GitLab Rails console.
For Omnibus installations:
sudo gitlab-rails console
For installations from the source:
sudo -u git -H bundle exec rails console -e production
For details, see starting a Rails console session.
Once the Rails console session has started, run the
Feature.disable commands accordingly. The specific flag can be found
in the feature’s documentation itself.
To enable a feature, run:
Example, to enable a fictional feature flag named
To disable a feature, run:
Example, to disable a fictional feature flag named
Some feature flags can be enabled or disabled on a per project basis:
Feature.enable(:<feature flag>, Project.find(<project id>))
For example, to enable the
:product_analytics feature flag for project
Feature.disable always return
nil, this is not an indication that the command failed:
irb(main):001:0> Feature.enable(:my_awesome_feature) => nil
To check if a flag is enabled or disabled you can use
Feature.disabled?. For example, for a fictional feature flag named
Feature.enable(:my_awesome_feature) => nil Feature.enabled?(:my_awesome_feature) => true Feature.disabled?(:my_awesome_feature) => false
When the feature is ready, GitLab removes the feature flag, and the option for enabling and disabling it no longer exists. The feature becomes available in all instances.