Establish a process for pre failures

Context

A release candidate (RC) is a GitLab package that includes the changes that will make it into the final self-managed release. An RC is created as part of the monthly release preparation, one day before the final tag.

Automate the creation of monthly releases in pr... (gitlab-com/gl-infra/software-delivery&1 - closed) aims to create the active stable branch one week earlier in the release schedule to allow for thorough testing and timely backports. The earlier stable branch creation changes the monthly release process to create at least two release candidates during the monthly release week preparation

• 2nd Wednesday of the month: RC and Stable branch creation
• Up to 3rd Tuesday of the month: Bug fixes are backported to the active stable branch (see 'Backporting process' section below)
• 3rd Tuesday of the month (Late EMEA or early AMER): Final RC is created
• 3rd Wednesday of the month Tag the final version
• 3rd Thursday of the month Release

Proposal: Establish a process for addressing pre failures

A process should be established to address pre failures:

• Deployment failures => EOC should be pinged
• Quality failures => Quality-on call should be pinged to determine if the failure is legit, a stage team should be involved
• The process / runbook should be documented in the release/docs repo
• The documentation should be linked in the Slack message

Exit criteria

• Create a doc about handling pre deployment failures gitlab-org/release/docs!907 (merged)
• Link this doc to the pre deployment failure Slack message https://ops.gitlab.net/gitlab-com/gl-infra/deploy-tooling/-/merge_requests/507