Commit f7faaf5c authored by Robert Speicher's avatar Robert Speicher

Document implicit feature flag checks

parent 44a6b8d4
...@@ -152,14 +152,31 @@ in RC1, followed by the feature flag being removed in RC2. This in turn means ...@@ -152,14 +152,31 @@ in RC1, followed by the feature flag being removed in RC2. This in turn means
the feature will be stable by the time we publish a stable package around the the feature will be stable by the time we publish a stable package around the
22nd of the month. 22nd of the month.
## Undefined feature flags default to "on" ## Implicit feature flags
By default, the [`Project#feature_available?`][project-fa], The [`Project#feature_available?`][project-fa],
[`Namespace#feature_available?`][namespace-fa] (EE), and [`Namespace#feature_available?`][namespace-fa] (EE), and
[`License.feature_available?`][license-fa] (EE) methods will check if the [`License.feature_available?`][license-fa] (EE) methods all implicitly check for
specified feature is behind a feature flag. Unless the feature is explicitly a feature flag by the same name as the provided argument.
disabled or limited to a percentage of users, the feature flag check will
default to `true`. For example if a feature is license-gated, there's no need to add an additional
explicit feature flag check since the flag will be checked as part of the
`License.feature_available?` call. Similarly, there's no need to "clean up" a
feature flag once the feature has reached general availability.
You'd still want to use an explicit `Feature.enabled?` check if your new feature
isn't gated by a License or Plan.
[project-fa]: https://gitlab.com/gitlab-org/gitlab-ee/blob/4cc1c62918aa4c31750cb21dfb1a6c3492d71080/app/models/project_feature.rb#L63-68
[namespace-fa]: https://gitlab.com/gitlab-org/gitlab-ee/blob/4cc1c62918aa4c31750cb21dfb1a6c3492d71080/ee/app/models/ee/namespace.rb#L71-85
[license-fa]: https://gitlab.com/gitlab-org/gitlab-ee/blob/4cc1c62918aa4c31750cb21dfb1a6c3492d71080/ee/app/models/license.rb#L293-300
### Undefined feature flags default to "on"
An important side-effect of the [implicit feature
flags][#implicit-feature-flags] mentioned above is that unless the feature is
explicitly disabled or limited to a percentage of users, the feature flag check
will default to `true`.
As an example, if you were to ship the backend half of a feature behind a flag, As an example, if you were to ship the backend half of a feature behind a flag,
you'd want to explicitly disable that flag until the frontend half is also ready you'd want to explicitly disable that flag until the frontend half is also ready
...@@ -171,7 +188,3 @@ to be shipped. You can do this via ChatOps: ...@@ -171,7 +188,3 @@ to be shipped. You can do this via ChatOps:
Note that you can do this at any time, even before the merge request using the Note that you can do this at any time, even before the merge request using the
flag has been merged! flag has been merged!
[project-fa]: https://gitlab.com/gitlab-org/gitlab-ee/blob/4cc1c62918aa4c31750cb21dfb1a6c3492d71080/app/models/project_feature.rb#L63-68
[namespace-fa]: https://gitlab.com/gitlab-org/gitlab-ee/blob/4cc1c62918aa4c31750cb21dfb1a6c3492d71080/ee/app/models/ee/namespace.rb#L71-85
[license-fa]: https://gitlab.com/gitlab-org/gitlab-ee/blob/4cc1c62918aa4c31750cb21dfb1a6c3492d71080/ee/app/models/license.rb#L293-300
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment