One additional thought to consider. Here’s an article from Hashicorp Terraform talking about Terraform Mono Repo vs. Multi Repo: The Great Debate
Think most people tend to think in terms of a mono repo, and it makes sense to start off that way. It so easy to think about things as one big “simple” button to press, and that’s it. The code starts to get complex, though. That’s the hidden cost. So at some point, folks break it out to multiple repos.
In the case of terraspace, this would be multiple terraspace projects. So you could consider:
- team = team_a - maps to a terraspace project
- env = qa - maps to TS_ENV
- account_type = service - maps to a terraspace stack
- region = us-east-2 - maps to AWS_REGION
Know this may not be a structure that most start with. It has some pros and cons.
The projects are decoupled. So you have to think about how to orchestrate multiple projects. If the projects are naturally decoupled, IE: the teams have been set up, so they operate independently, then there’s no orchestration, and it’s actually a pro.
But there’s likely a “core” or “platform” team that’s responsible for shared infrastructure components like VPC or Clusters. Depending on where you’re at, the share components can be managed as separate terraspace projects, and the coordination can be minimized. Some folks like the mono approach, and some like the multiple repo approach. 