Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Production Readiness Process

The Production Readiness process defines requirements for a service, or a group of services, to be running in a production environment and receiving customer facing traffic.

Starting a proposal

The Production Readiness process is authored by the DRI of the work that is being delivered.

The author creates an issue using the issue template in the readiness project.

Once the issue is created, the author creates a merge request in the readiness project based on the structure defined in the project readme, and the content of the issue.

As a reference, see the example merge request.

Once the proposal is ready for review, assign the team members who worked on the task for initial review.

Once the initial review is completed, the merge request should be merged. Next, the author and initial reviewers should propose candidates for final review. In principle, further reviewers should have:

When final reviewers have been selected, author creates a merge request for each group of candidates conducting the final readiness review.

By creating a merge request, the questions and answers are raised at specific points in the documentation. Information in issues can easily get lost given that the document is point of discussion. See an example of final review merge request.

Final review merge request can be created using the following guideliness:

Reviewing a proposal

As a reviewer of the Production Readiness proposal, your task is to think with the author of the proposal on whether the information provided in the proposal is sufficient for a service to run in production. The proposal author is still the DRI and they are ultimately responsible for putting the service in production.

In general, consider how sections listed in the issue template are addressed. It is important that you highlight any shortcomings that you observe. Not every detail will need to be addressed, but every detail raised will be informing the next steps.

When you get mentioned in a merge request, assign yourself the merge request in question to indicate that you will participate in the review.

Use the Show all lines option in the merge request diff to review the proposal line by line. Leave questions inline as you would with regular code review. Once sufficiently happy with the changes addressing raised remarks, unassign yourself from the issue to indicate that your part of review is completed.

Once all comments have been addressed or due date of the merge request has been reached, changes will be merged and the author of the proposal will continue with enabling the service in production.

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license