As per [the handbook description](https://about.gitlab.com/handbook/engineering/infrastructure/production/readiness/#starting-a-proposal)
this issue is a tool that will help prepare the readiness document. **It's not the production readiness
document itself!**.
## Production Readiness
**The readiness documentation should be added to the [project](https://gitlab.com/gitlab-com/gl-infra/readiness/)
with a merge request, where different interested parties can collaborate. You can start with a simple
one-page proposal as in the [example merge request](https://gitlab.com/gitlab-com/gl-infra/readiness/-/merge_requests/1).**
For any new or changes to a feature or service in production, the questions in this guide will help to make these changes more robust when they are enabled on GitLab.com.
Before starting, please review the [Production Readiness Review](https://about.gitlab.com/handbook/engineering/infrastructure/production/readiness/) document in the handbook.
**This issue serves as a tracking issue to guide you through the readiness review. It's not the production readiness document itself!**.
**The readiness documentation will be added to the [project](https://gitlab.com/gitlab-com/gl-infra/readiness/) with a merge request, where different interested parties can collaborate.**
---
For any new or existing large feature set the questions in this guide help to make them more robust and prevent impacting the availability of our platform.
## Readiness MR
{+ Add link to the readiness MR when it is created +}
## Reviewers
The reviewers should be filled in as one of the steps of the checklist below.
If a reviewer in the "Mandatory" section is not allocated, please add the reason why next to the name.
**The reviewer will check the box next to their name when the review is complete**
### Mandatory
- [ ] Reliability: {+ reviewer name +}
- [ ] Delivery: {+ reviewer name +}
- [ ] InfraSec: {+ reviewer name +}
Initially, this guide is likely to be used by Production Engineers who are embedded with other teams working on existing services and features. However, anyone working on a new feature set is encouraged to use this guide as well.
### Optional
The goal of this guide is to help others understand how the new feature set may impact the rest of the (production) system; what steps need to be taken (besides deploying this new feature) to ensure that it can be properly managed; and to understand what it will take to manage the reliability of the new system / feature / service beyond its' initial deployment.
_Delete these reviewers if they do not apply_
For readiness review of *infrastructure services* use this issue template instead:
[service_readiness.md](service_readiness.md)
- [ ] Development: {+ reviewer name +}
- [ ] Scalability: {+ reviewer name +}
- [ ] Database: {+ reviewer name +}
While we strive and encourage all parts of this document to be filled out, all
sections are mandatory and shall considered a blocker prior to the review being
completed. If some questions do not have an answer, or are potentially not
relevant to the service in question, leave the question intact and state the
reasons for not having an answer or note why it isn't relevant.
## Readiness Checklist
This Guide is just that, a Guide. If something is not asked, but should be, it
is strongly encouraged to add it as necessary. If you feel like something is missing, please consider submitting an MR against the template.
The following items should be completed by the person initiating the readiness review:
- [ ] Create this issue and assign it to yourself. Set a due-date for when you believe the readiness will be completed (this can be updated later if necessary).
-[ ] Review the [Production Readiness Review](https://about.gitlab.com/handbook/engineering/infrastructure/production/readiness/) handbook page.
- [ ] In the "Reviewers" section above, add the reviewer names. Names will be assigned by reaching out to the engineering manager of the corresponding team.
- [ ] Create the first draft of the readiness review by copying the template below and submitting an MR, add the label ~"workflow-infra::In Progress" to this issue.
- [ ] Add a link to the MR in the "Readiness MR" section at the top of this issue
- [ ] Assign the initial set reviewers to the MR. There can be multiple iterations of MR if needed, often it is helpful to have the first draft reviewed by team members in the same team. **Approval of the MR does not mean the readiness document is approved, approvals will be done later on this issue.**
- [ ] When last review of the MR is complete, ask the reviewers in the "Reviewers" section above to check the box next to their name if they are satisfied with the review and have no more questions or concerns.
- [ ] (Optional) If it is later decided to not proceed with this proposal, add ~"workflow-infra::Cancelled" and close this issue
When all boxes have been check in the "Reviewers" section, add the ~"workflow-infra::Done" label and close the issue.
## Readiness MR Template
Expand the section below to view the readiness template, this will be the starting point for the readiness merge request.
**Create `<name>/index.md` as a new merge request with the following content where <name> is something short and descriptive for the change being proposed**
<details>
_While it is encouraged for parts of this document to be filled out, not all of the items below will be relevant. Leave all non-applicable items intact and add the reasons for why in place of the response._
_This Guide is just that, a Guide. If something is not asked, but should be, it is strongly encouraged to add it as necessary._
## Summary
...
...
@@ -106,3 +141,5 @@ is strongly encouraged to add it as necessary. If you feel like something is mi
- [ ] **Describe the load test plan used for this feature. What breaking points were validated?**
- [ ] **For the component failures that were theorized for this feature, were they tested? If so include the results of these failure tests.**
- [ ] **Give a brief overview of what tests are run automatically in GitLab's CI/CD pipeline for this feature?**