Feature flag rollout: `async_mr_pipeline_creation`
## Summary
This issue is to roll out [the async pipeline creation for new merge requests](https://gitlab.com/groups/gitlab-org/-/epics/10991) on production,
that is currently behind the `async_mr_pipeline_creation` feature flag.
**Related MR:** https://gitlab.com/gitlab-org/gitlab/-/merge_requests/217381
## Owners
- Most appropriate Slack channel to reach out to: `#g_code_review`
- Best individual to reach out to: @marc_shaw
## Expectations
### What are we expecting to happen?
When enabled, pipeline creation for new merge requests will be performed asynchronously via `MergeRequests::CreatePipelineWorker` instead of synchronously in `NewMergeRequestWorker`. This should reduce the P90 latency of `NewMergeRequestWorker` from over 3 seconds to under 1 second (S3 criteria target).
### What can go wrong and how would we detect it?
- Pipeline creation could fail silently or be delayed, causing merge requests to appear without pipelines longer than expected
- Monitor `NewMergeRequestWorker` latency metrics and pipeline creation success rates
- Watch for increased errors in `MergeRequests::CreatePipelineWorker`
- Check for user reports of missing pipelines on newly created merge requests
## 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 has 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 async_mr_pipeline_creation 50 --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 async_mr_pipeline_creation true --dev --pre --staging --staging-ref`
- [ ] Verify that the feature works as expected.
The best environment to validate the feature in is [`staging-canary`](https://about.gitlab.com/handbook/engineering/infrastructure/environments/#staging-canary) as this is the first environment deployed to. Make sure you are [configured to use canary](https://next.gitlab.com/).
- [ ] If the feature flag causes end-to-end tests to fail, disable the feature flag on staging to avoid blocking [deployments](https://about.gitlab.com/handbook/engineering/deployments-and-releases/deployments/).
### Before production rollout
- [ ] If the change is significant and you wanted to announce in [#whats-happening-at-gitlab](https://gitlab.enterprise.slack.com/archives/C0259241C), it best to do it before rollout to `gitlab-org/gitlab-com`.
### Specific rollout on production
For visibility, all `/chatops` commands that target production must be executed in the [`#production` Slack channel](https://gitlab.slack.com/archives/C101F3796)
and cross-posted (with the command results) to the responsible team's Slack channel.
- Ensure that the feature MRs have been deployed to both production and canary with `/chatops run auto_deploy status <merge-commit-of-your-feature>`
- [ ] For **project-actor**: `/chatops run feature set --project=gitlab-org/gitlab,gitlab-org/gitlab-foss,gitlab-com/www-gitlab-com async_mr_pipeline_creation true`
- [ ] Verify that the feature works for the specific actors.
### Preparation before global rollout
- [ ] Set a milestone to this rollout issue to signal for enabling and removing the feature flag when it is stable.
- [ ] Check if the feature flag change needs to be accompanied with a [change management issue](https://about.gitlab.com/handbook/engineering/infrastructure-platforms/change-management/#feature-flags-and-the-change-management-process). Cross link the issue here if it does.
- [ ] Ensure that you or a representative in development can be available for at least 2 hours after feature flag updates in production.
- [ ] Ensure that documentation exists for the feature, and the [version history text](https://docs.gitlab.com/development/documentation/feature_flags/#add-history-text) has been updated.
- [ ] Notify the [`#support_gitlab-com` Slack channel](https://gitlab.slack.com/archives/C4XFU81LG) and your team channel.
### Global rollout on production
For visibility, all `/chatops` commands that target production must be executed in the [`#production` Slack channel](https://gitlab.slack.com/archives/C101F3796)
and cross-posted (with the command results) to the responsible team's Slack channel.
- [ ] [Incrementally roll out](https://docs.gitlab.com/development/feature_flags/controls/#process) the feature on production.
- `/chatops run feature set async_mr_pipeline_creation 10 --actors`
- `/chatops run feature set async_mr_pipeline_creation 25 --actors`
- `/chatops run feature set async_mr_pipeline_creation 50 --actors`
- `/chatops run feature set async_mr_pipeline_creation 100 --actors`
- Between every step wait for at least 15 minutes and monitor the appropriate graphs on https://dashboards.gitlab.net.
- [ ] After the feature has been 100% enabled, wait for at least one day before releasing the feature.
### Release the feature
After the feature has been deemed stable, the [clean up](https://docs.gitlab.com/development/feature_flags/controls/#cleaning-up)
should be done as soon as possible to permanently enable the feature and reduce complexity in the codebase.
- [ ] Create a merge request to remove the `async_mr_pipeline_creation` feature flag. The MR should include:
- Remove all references to the feature flag from the codebase.
- Remove the YAML definitions for the feature from the repository.
- [ ] Ensure that the cleanup MR has been included in the release package.
- [ ] Once the cleanup MR has been deployed to production, clean up the feature flag from all environments: `/chatops run feature delete async_mr_pipeline_creation --dev --pre --staging --staging-ref --production`
- [ ] Close this rollout issue.
## Rollback Steps
- [ ] This feature can be disabled on production by running the following Chatops command:
```
/chatops run feature set async_mr_pipeline_creation false
```
- [ ] Disable the feature flag on non-production environments:
```
/chatops run feature set async_mr_pipeline_creation false --dev --pre --staging --staging-ref
```
- [ ] Delete feature flag from all environments:
```
/chatops run feature delete async_mr_pipeline_creation --dev --pre --staging --staging-ref --production
```
issue