Issue template created detailing how to accomplish Terraform changes in Production
Current Situation
Terraform changes can be applied as self-reviewed MRs and applied directly to Production. This has inherent risk in that what one operator could see as a minor change, could have significant consequences if the infrastructure where the change is being applied is not set up as expected by the operator.
Currently we use the MR setting "Default description template for merge requests" for the project to detail steps.
Desired Outcome
Team workflows are updated to ask those making TF changes to take an issue-first approach to the change. These changes use an issue template in the https://gitlab.com/gitlab-com/gl-infra/infrastructure project meant to accompany and drive TF MRs. This template details at least the following:
GCP Infrastructure changes
-
An external review has been conducted of the related MR -
Plan has been reviewed and a dry-run conducted to test the outcome of the TF change to be applied
Cloudflare setup changes
-
Has the same change been made in staging? How long has it been running in staging? -
Is this rule in the right order of most specific to least specific (top to bottom)? -
Is this change as granular as possible and broad as necessary? -
Use example.com instead of *example.com for matching HTTP and HTTPS traffic. -
New/changed forwarding page rules are not susceptible to redirect loop(s) -
Is the priority correct? Higher numbers in terraform represent a lower match order in the web interface.
During application of the change
-
An additional team member is serving as a second person and you are both in the incident zoom during the application
Acceptance Criteria
-
Issue template is created and MR template field in https://ops.gitlab.net/gitlab-com/gitlab-com-infrastructure/ points back to the need to create an issue to accompany the change. -
Team workflows needing update are identified and updated.
related to: production#3578 (closed)