Feature Flags support

[glensc]

GitLab has feature flags:

With feature flags, you can deploy your application’s new features to production in smaller batches. You can toggle a feature on and off to subsets of users, helping you achieve Continuous Delivery. Feature flags help reduce risk, allowing you to do controlled testing, and separate feature delivery from customer launch.

• https://docs.gitlab.com/ee/operations/feature_flags.html

API description:

• https://docs.gitlab.com/ee/api/feature_flags.html

I can't seem be able to find feature flags from the feature list:

• https://gitlabform.github.io/gitlabform/features/

nor from issues or pull requests:

• https://github.com/gitlabform/gitlabform/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+feature+flags
• https://github.com/gitlabform/gitlabform/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc+feature+flags

please add support controlling feature flags:

• add feature flag
• remove feature flag
• add feature flag only if missing

[amimas]

Thanks for the idea @glensc . I think it should probably be another top-level key under a project similar to branches, deploy_keys, hooks, etc. Can you suggest a full config syntax for this feature? Some of the other configs supports enforce key so that if something only exists in gitlab but not in gitlabform config, they'll be removed. Should that be included too? BTW - would you be able to help implement it?

[glensc]

projects_and_groups:
  group_1/project_1:
    feature_flags:
      awesome_feature:
        name: awesome_feature
        description: "This feature is about merge train"
        active: true,
        scopes: []
        strategies: ...
        strategies:name: ...

• https://docs.gitlab.com/ee/api/feature_flags.html#create-a-feature-flag

from the options only "name" is required, the others ("id", "version") are internal and should be provided by gitlabform.

I personally, don't know much about strategies, I just fill from the UI:

• name
• description
• active
• environment (scopes)

so that could be the minimum scope implemented.

also, it's important to have configuration not to overwrite the value of "active". the reason is that the current active flag is changed by product manager (or the like), not tied to configuration of the feature flag.

don't know whether or how other configuration keys handle this. could be similar to them.

and if there is nothing similar for other keys, could implement like that:

• if "active" key is not present, do not update it
• for new flags hardcode "true" or "false" value. not whatever seems logical or convenient. in gitlab UI default is "true"

[amimas]

Thanks for all that details @glensc . I haven't used GitLab's "Feature flags" yet, but here's my thought.

I like your config syntax suggestion. One minor tweak I would propose is to not have the name key in the config. So, it'll look something like this:

projects_and_groups:
  group_1/project_1:
    feature_flags:
      awesome_feature:
-       name: awesome_feature
        description: "This feature is about merge train"
        active: true,
-        scopes: []

The reason for removing name is because it becomes duplicate config. I think gitlabform should use the key named awesome_feature and use that for the name value. This is consistent with the pipeline schedule config pattern, where the config key is used as the schedule's description. Also, I don't see scope in GitLab's API. Maybe you meant that to strategies:scopes because I see that one exists.

also, it's important to have configuration not to overwrite the value of "active". the reason is that the current active flag is changed by product manager (or the like), not tied to configuration of the feature flag.

I'm not too clear or maybe on the fence on this. I think gitlabform should perform based on whatever is in the config. If active is not present, default should follow whatever Gitlab does. If active key is present in the config, then forward the value to gitlab's api. It's possible I completely misunderstood your explanation :)

As for the config syntax related to strategies, maybe we can just write it in a more human friendly way:

projects_and_groups:
  group_1/project_1:
    feature_flags:
      awesome_feature:
        description: "This feature is about merge train"
        active: true,
        strategies:
          - strategy-foo: # This is just a label
            name: gradualRolloutUserId
            parameters:
              groupId: default
              percentage: 25
            scopes:
              - environment_scope: staging
          - strategy-bar: # This is just a label
            name: gradualRolloutUserId
            parameters:
              groupId: default
              percentage: 35
            scopes:
              - environment_scope: qa

Maybe the strategies should be implemented separately. It might be easier to implement the feature flags configs first. Within strategies config there are multiple delete type actions; e.g: strategies:_destroy, strategies:scopes:_destroy.

[glensc]

If active is not present, default should follow whatever Gitlab does. If active key is present in the config, then forward the value to gitlab's api

if it works like this, then perfect. but if will overwrite active state, I can't possibly use this feature.

the use case is like this:

1. configure project to add feature flag
2. re-run it at any time
3. should not interfere with feature flag active value because the project is in "production"

I don't know how to better explain this use case.

[TimKnight-DWP]

@glensc I agree with you, toggling on/off a Feature Flag is something we do want people to be able to quickly do in UI without GLF reverting, for example:

I create the Feature Flag as "off",
develop and push my code to branch,
decide it's good to go,
toggle on,
discover there is a critical bug,
I want to very quickly turn it off again without needing to raise a PR into my GLF config, wait for that to run etc...

We should allow people to set "active" in the config and if it's there use it to apply that to Gitlab itself even if there is drift.

But if people do not set "active" in the config:

• When creating a Flag we should ideally let GitLab set the default when the item is CREATED
• When updating a Flag we should not change the active state in Gitlab