@@ -356,7 +356,7 @@ Besides, we try to apply some best practices when doing Merge Requests:
- GitLab team is globally distributed, so think about timezone when assigning someone as reviewer.
- Project - The reviewer should be knowledgeable or at least familiarized with the project, for example, release-tools reviews are normally handled by backend engineers, while k8s-workloads reviews are handled by SREs.
- Context - If you're working closely with a peer, it's recommended to assign it to this team member for shorter review cycles.
- Release manager (or capacity) - If a team member is a [release manager](https://about.gitlab.com/community/release-managers/) and they're working on a release task, they should not be bothered with reviews.
- Release manager (or capacity) - If a team member is a [release manager](/handbook/engineering/releases/release-managers/) and they're working on a release task, they should not be bothered with reviews.
- The usual [code-review turnaround](/handbook/engineering/workflow/code-review/#review-response-slo) is two business days.
- This doesn't apply if the merge request is associated with a ~Delivery::P1 item. In that case, the Merge Request review has to be treated with priority and urgency.
- If the merge request has all the required approvals it can be merged by the author.
@@ -388,7 +388,7 @@ The Delivery team officially [came into existence on 2018-10-23](https://gitlab.
All throughout GitLab's existence, Release Management had been a monthly rotating role served by developers. The idea behind it was to keep developers close to the whole lifecycle of the software they create, and ensure that they automate their work. This worked well until the number of application changes, and developer tasks grew too large for anyone to handle as a secondary task. The event that indicated the need for a change was a near miss event near the end of 2017, when the first Release Candidate was deployed to GitLab.com just 2 days before the 22nd. That whole month was riddled with challenges, from release managers struggling to deliver their day to day development tasks and RM tasks, to multiple unsuccessful deployments to GitLab.com. Most importantly, this was a first indication that the company was growing and that the processes that worked previously, might need to change to accommodate the larger growth that was planned.
After some internal discussions, we entered 2018 with an attempt to [work on process improvements](https://gitlab.com/gitlab-org/release/tasks/-/issues/39), rather than changing everything in one go. We went from a monthly rotation to two month [release manager rotation](https://about.gitlab.com/community/release-managers/), started [noting down spent time](https://gitlab.com/gitlab-org/release/tasks/-/issues/1). Over the next several months we'd seen general stabilization of the process but it became apparent that spending 4 engineers time in Release Manager rotation was not getting us anywhere closer to improving the deployment process for GitLab.com, and with each developer we hired the task list grew bigger.
After some internal discussions, we entered 2018 with an attempt to [work on process improvements](https://gitlab.com/gitlab-org/release/tasks/-/issues/39), rather than changing everything in one go. We went from a monthly rotation to two month [release manager rotation](/handbook/engineering/releases/release-managers/), started [noting down spent time](https://gitlab.com/gitlab-org/release/tasks/-/issues/1). Over the next several months we'd seen general stabilization of the process but it became apparent that spending 4 engineers time in Release Manager rotation was not getting us anywhere closer to improving the deployment process for GitLab.com, and with each developer we hired the task list grew bigger.
The initial discussion on [what is in front of us to achieve Continuous Delivery](https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/1) on GitLab.com exposed a clear need for a team focused on this specific task.
@@ -46,7 +46,7 @@ The end-to-end process consists on the following stages:
1.**GitLab.com deployments** - From the start of the milestone up to one week before the release date, GitLab.com receives multiple
deployments per day. For application changes to be included in a monthly release they need to be successfully deployed to GitLab.com.
1.**Release candidate** - A test [release candidate (RC)](#what-is-a-release-candidate-and-when-are-they-created) is created, along with a stable branch for the targeted [semver](https://semver.org) version. The release candidate package is built,
tested and deployed to the [pre environment](/handbook/engineering/infrastructure-platforms/environments/#pre). A successful outcome indicates this package can be used as the final version. At this point [Release Managers](https://about.gitlab.com/community/release-managers/) will
tested and deployed to the [pre environment](/handbook/engineering/infrastructure-platforms/environments/#pre). A successful outcome indicates this package can be used as the final version. At this point [Release Managers](/handbook/engineering/releases/release-managers/) will
announce the final commit to be included in the release.
1.**Tag** - Release Managers tag the final version of the release based on the release candidate. The release is built and deployed to the [Release environment](/handbook/engineering/infrastructure-platforms/environments/#release).
1.**Release** - On the release day, the release packages are published.
@@ -194,7 +194,7 @@ Merge Requests that have been included in the monthly release will receive [a la
### Who are the Release Managers for release X?
You can find this out by taking a look at the [GitLab Release Managers](https://about.gitlab.com/community/release-managers/) schedule.
You can find this out by taking a look at the [GitLab Release Managers](/handbook/engineering/releases/release-managers/) schedule.
### What is a release candidate and when are they created?
