Where root modules live, how state is partitioned across them, the project factory that stamps out a correct GCP project every time, and whether environments should be directories or workspaces — the layout decisions that decide whether the fiftieth project is as boring to add as the first.
5 topics
Once Hatch has more than one project and more than one environment, the question stops being "how do I write this resource" and becomes "how do I lay out an org so growth is boring." By this chapter the Hatch org has folders platform, apps, and data, a project per environment, and a hatch-tfstate bucket holding everyone's state. What it needs is a structure that makes the fiftieth project as routine to add as the first.
This chapter is about that structure. One root module per project-per-environment with its own state, the terraform-google-modules/project-factory pattern that makes "a correct Hatch project" one module call, the directories-versus-workspaces argument that GCP's project hierarchy settles, the native DRY tools that keep environment directories thin, and the point at which Terragrunt earns the cost of a second tool.