Turning one engineer running apply from a laptop into a team where every change flows through a reviewed pipeline — shared GCS state, keyless CI on Cloud Build and GitHub Actions, Google's managed Infrastructure Manager, drift detection, and a price tag on every plan.
6 topics
A solo project survives on one engineer, one state file, and a laptop running apply. A team does not. The moment a second person needs to change the same infrastructure, you need shared state that locks, a pipeline that reviews and applies changes, and an identity model that lets CI talk to GCP without a key file lying around. This chapter is the jump from solo to team.
The running example is Layer B — the Hatch org — whose state lives in the hatch-tfstate bucket and whose CI runs from hatch-io/infrastructure, authenticating through Workload Identity Federation with no keys, both established in Chapter 2. Here we make that bucket safe for many hands, run Terraform in Cloud Build and in GitHub Actions, weigh Google's managed Infrastructure Manager against self-hosting, catch out-of-band drift, and put a cost estimate on every pull request.