Updates to Readiness process in infrastructure
There are some aspects of the Infrastructure Readiness review that are confusing due to how it evolved over time. This issue tracks some small iterative changes that I think will help to add clarity on how it is used, and to track ongoing reviews.
-
gitlab-com/www-gitlab-com!100910 (merged) Reframe readiness to be not service oriented, but functionality and large feature-set oriented. Give specific examples for when we require a readiness review in the handbook based on prior experience so it is clearer when a readiness review is necessary. We do this already in the template but this should be updated in the handbook. Examples would include: - New services like KAS
- Migrating infrastructure
- New datastores
- New functionality that stores user data like error tracking
-
readiness!108 (merged) Update the issue template and handbook to switch the current issue template to be exclusively a tracking issue, making an MR mandatory for all readiness reviews. The issue will be used to check off that departments have reviewed and approved readiness before we move to production. Approvals will also be tracked on MR, but since readiness may have multiple review cycles I would like to use the issue as the central place to check off that it has been reviewed -
readiness!108 (merged) Move the readiness review template in a <details>...</details>
to be pasted into an MR, further emphasizing that this process is MR oriented, not issue oriented. -
gitlab-com/www-gitlab-com!101085 (merged) Readiness should be the single starting point for all signficant functionality and feature updates to .com, this should be emphasized in the handbook on the main infrastructure page, with a pointer from the team "how to get assistance" sections. -
Announce change in slack channels #whats-happening-at-gitlab
with links to a few other backend/infra channels.
Edited by John Jarvis