Improve golang upgrade process documentation
Summary
I recent outage on gitlab.com gitlab-com/gl-infra/production#5521 (closed) was caused by a golang upgrade from 1.16.x to 1.17
As an result we want to improve the process we take for golang upgrades. The current process is documented here: https://docs.gitlab.com/ee/development/go_guide/index.html#updating-go-version
From feedback in gitlab-com/gl-infra/production#5533 (closed), we know we want the process to:
- Add a step for opening and epic for the upgrade, to create a point of cross-team/project engagement and discussion
- And example of this is the epic for the ruby 3.0 update: &5149 (closed)
- Include a step that ensure the new version of golang has been used in the gitlab GDK prior to the CNG and Omnibus MRs
- Include steps for announcing that the change is happening
- Announce in internal channels after its available in the GDK, so developers can test
- Announce again when the CNG and Omnibus MRs are merged
- Describe the sort of testing that should occur prior to merge
Feature Change Lock
This issues is part of gitlab-org/distribution/team-tasks#925 (closed)
Edited by Robert Marshall