The Production Readiness Review is a process that helps identify the reliability needs of a service, feature or significant change to infrastructure for GitLab.com. It loosely follows the production readiness review from the SRE book. The goal of the readiness review is to make sure we have enough documentation, observability, and reliability for the feature, change, or service to run at GitLab.com production scale.
For GitLab, this review is meant to facilitate collaboration between Service Owners, Application Security, and Site Reliability teams to share and help bridge any gaps about a new service. The review document will serve as a snapshot of what is being deployed and the discussions that surround it. It is not intended to be constantly updated.
The review starts by creating a new issue in the readiness project. After this, an MR is created using the example template which is the baseline for the review. We prefer to use an MR for reviewing the readiness document since it allows for inline comments, threaded discussions, and explicit assignments for review.
The readiness review MR may go through multiple rounds of review, including merges to mainline. It is recommended to send the first review to team members who are closest to the service or feature. Though most essential readiness questions should be captured in the template, it is fine to add more details as necessary. All non-applicable sections should be noted in the MR.
The readiness review needs to be approved by all required reviewers before the change is deployed and is taking production traffic. It is important to start the readiness as early as possible, as early as development and design. If it's not clear on what is needed to make a service scale for GitLab SaaS, engage with SREs on the design phase to receive guidance on the direction.
The Production Readiness process is authored by the DRI of the work that is being delivered.
The production readiness review process has been used for a wide range of changes to GitLab.com. These include new services, larger features in GitLab Rails, infrastructure migrations, and architecture changes. For examples see folders in the readiness project; note that every review is different so it is best to always start from the example template instead of an existing review.
Show all linesoption in the merge request diff to review and comment on unchanged lines. Leave questions as you would with regular code review.
Once all discussions have been addressed all mandatory items have satisfactory answers, the author will request approvals in the tracking issue in the "Reviewers" section of the tracking issue. Following this, the issue will be closed and the change can be applied in production.