0

As part of a new job role, I have started learning Terraform recently. Before, my main orchestration/provisioning tool was Ansible, and the best practice at my previous place was to hold the state for the entire project in a single repository (adding company roles as submodules, if need be).

At my new job, the team uses a lot of small repositories, each for a single TF 'project' or even part of the environment (e.g. one repository configures the underlying VPC and region-related stuff, and another configures the app resources within that VPC). Is it a common best practice for Terraform to keep that degree of separation between repositories (aside from separating ready-made modules?)

Improve this question
1
  • IMHO "best practice" is often just another opinion. - To add another opinion, rather than asking the internet, consider asking your colleagues and team. Especially since you're a new joiner, there is nothing wrong with asking a naive question why they are doing the things they do in a particular way... The answer may surprise you (in either a good or bad way )
    – HBruijn
    Commented Apr 8 at 12:04

1 Answer 1

Reset to default
0

Lots of different opinions on this, including the (mild) uproar not long ago when AWS released some info on how they'd rearchitected back to a monolith.

What I would try to consider if I were setting this up:

  • Scale. How many modules do you have to manage? Is having your reusable TF modules each in a separate repo going to present challenges to managing them, or is having them all in the same repo easier? Are you at that scale yet? Do you think you will be?
  • Coordination. Not sure if that's the best word for it, but having different repos do different parts of the same provisioning process doesn't sound like my preferred approach, as it makes the dependencies potentially hard to track and debug. What if something like the networking set up hasn't been done? There are bound to be ways to handle this but it's something else to consider.

Similarly, if you have many accounts to manage, having each account set up in a different repo means that if you need to apply changes to all of them, you may have a lot of PRs to raise.

My initial instinct is probably to have modules in individual repos, but deployments (which glue modules together) in one large monorepo. But that's just my gut feel, with no context, on the internet...

Again, this is just my opinion. SF doesn't always like opinion questions so this may get closed, but if not - some food for thought!

Finally (quick edit) - remember that mostly this is not what AWS calls a 1-way door. You can always rearchitect, it just might not be trivial. So start with what's good for now, and what should be good for a little while, and change if need be.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .