[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
- In
-
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