Skip to content

[Feature flag] Enable async_merge_request_pipeline_creation

Summary

This issue is to roll out the feature on production, that is currently behind the async_merge_request_pipeline_creation feature flag.

Owners

  • Most appropriate Slack channel to reach out to: #g_pipeline_authoring
  • Best individual to reach out to: @lauraXD @bsandlin @avielle

Rollout Steps

Note: Please make sure to run the chatops commands in the Slack channel that gets impacted by the command.

Rollout on non-production environments

  • Verify the MR with the feature flag is merged to master and have been deployed to non-production environments with /chatops run auto_deploy status <merge-commit-of-your-feature>

  • Deploy the feature flag at a percentage (recommended percentage: 50%) with /chatops run feature set <feature-flag-name> <rollout-percentage> --actors --dev --pre --staging --staging-ref

  • Monitor that the error rates did not increase (repeat with a different percentage as necessary).

  • Enable the feature globally on non-production environments with /chatops run feature set <feature-flag-name> true --dev --pre --staging --staging-ref

  • Verify that the feature works as expected. The best environment to validate the feature in is staging-canary as this is the first environment deployed to. Make sure you are configured to use canary.

  • If the feature flag causes end-to-end tests to fail, disable the feature flag on staging to avoid blocking deployments.

    • See #qa-staging Slack channel and look for the following messages:
      • test kicked off: Feature flag <feature-flag-name> has been set to true on **gstg**
      • test result: This pipeline was triggered due to toggling of <feature-flag-name> feature flag

For assistance with end-to-end test failures, please reach out via the #test-platform Slack channel. Note that end-to-end test failures on staging-ref don't block deployments.

Preparation before global rollout

  • Ensure that you or a representative in development can be available for at least 2 hours after feature flag updates in production. If a different developer will be covering, or an exception is needed, please inform the oncall SRE by using the @sre-oncall Slack alias.
  • Ensure that documentation exists for the feature, and the version history text has been updated.
  • Leave a comment on the feature issue announcing estimated time when this feature flag will be enabled on GitLab.com.
  • Ensure that any breaking changes have been announced following the release post process to ensure GitLab customers are aware.
  • Notify the #support_gitlab-com Slack channel and your team channel (more guidance when this is necessary in the dev docs).
  • Ensure that the feature flag rollout plan is reviewed by another developer familiar with the domain.

Rollback Steps

  • This feature can be disabled on production by running the following Chatops command:
/chatops run feature set <feature-flag-name> false
  • Disable the feature flag on non-production environments:
/chatops run feature set <feature-flag-name> false --dev --pre --staging --staging-ref
  • Delete feature flag from all environments:
/chatops run feature delete <feature-flag-name> --dev --pre --staging --staging-ref --production
Edited by Laura Montemayor