Skip to content

[Feature flag] Rollout of `feature_flag_contextual_issue`

What

Remove the :feature_flag_contextual_issue feature flag ...

Related #320735 (closed)

Owners

  • Team: ~"group::release"
  • Most appropriate slack channel to reach out to: #s_release
  • Best individual to reach out to: @shinya.maeda

Expectations

What are we expecting to happen?

Users can use feature flag references in GFM.

What might happen if this goes wrong?

As long as we trust the logical reviewing by the domain expert, manual QA that conducted during the development and staging QA, no production incident is expected.

This feature is to allow users to create a reference link for feature flags. If we suspect the above logical reviewing had a flaw, it could raise an error when a user posts a comment, for example, the system could fail to execute a database query when there is a SQL corruption.

The generated references are persisted into the notes table. This means if the reference formatter has an unknown bug, corrupted references could be persisted into the database table. In this case, users will not see the reference correctly (e.g. tooltip). We would not ship a database migration in such case, as this feature is just an auxiliary part in UX and not critical on the core part of the system.

The application code change was introduced by a single MR, hence all changes can be viewed in the MR diff. Namely, Banzai::Filter::FeatureFlagReferenceFilter and Operations::FeatureFlag had most of the changes.

What can we monitor to detect problems with this?

Since there are no performance impact is expected, monitoring with Prometheus/Grafana would not be useful. In the above hypothetical incident scenario, looking at the error rate on POST /notes endpoint could be helpful to notice the error. Hence, Sentry would be better fit here.

Needless to say, monitoring an issue tracker on gitlab-org/gitlab is going to be conducted.

Beta groups/projects

If applicable, any groups/projects that are happy to have this feature turned on early. Some organizations may wish to test big changes they are interested in with a small subset of users ahead of time for example.

  • gitlab-org/gitlab project
  • gitlab-org/gitlab-com groups
  • ...

Roll Out Steps

  • Enable on staging (/chatops run feature set feature_flag_contextual_issue true --staging)
  • Test on staging
  • Ensure that documentation has been updated
  • Enable on GitLab.com for individual groups/projects listed above and verify behaviour (/chatops run feature set --project=gitlab-org/gitlab feature_flag_contextual_issue true)
  • Coordinate a time to enable the flag with the SRE oncall and release managers
    • In #production mention @sre-oncall and @release-managers. Once an SRE on call and Release Manager on call confirm, you can proceed with the rollout
  • Announce on the issue an estimated time this will be enabled on GitLab.com
  • Enable on GitLab.com by running chatops command in #production (/chatops run feature set feature_flag_contextual_issue true)
  • [-] Cross post chatops Slack command to #support_gitlab-com (more guidance when this is necessary in the dev docs) and in your team channel
  • Announce on the issue that the flag has been enabled
  • Remove feature flag and add changelog entry
  • After the flag removal is deployed, clean up the feature flag by running chatops command in #production channel

Rollback Steps

  • This feature can be disabled by running the following Chatops command:
/chatops run feature set --project=gitlab-org/gitlab feature_flag_contextual_issue false
Edited by Shinya Maeda