Single vs Multiple Repos for Ref Architecture
We've just started using the Reference Architecture and it seems very dependent on having the one repository for everything but this goes against everything that I've ever known - from my experience, repositories should be purposeful and not monolithic. Is there a way to have the Reference Architecture used with multiple repostories?
You can reorganize the reference architecture in any way you like. E.g., you can create multiple `infrastructure-live` repos and copy paste the folder and common files to the new repos to split it out. Note that migrating to multi-repo has a few gotchas that you will want to keep in mind: - `terragrunt` currently doesn't support remote dependencies. What this means is that if a `terragrunt` module depends on anothe resource (e.g., EKS depending on VPC), then you will need to make sure that the repo contains both the code for VPC and EKS so that the dependency references can work. If you want to further split off, then just be aware that you will no longer be able to use `dependency` blocks to link the two, requiring either hard coding or a look up with the AWS CLI. - `terragrunt` currently doesn't support remote includes. What this means is that depending on how you split off the `infrastructure-live` repo, you may end up with code duplication as you will no longer be able to include common values via the `_envcommon` pattern. - The current state file path is dependent on relative paths between the root `terragrunt.hcl` and the child `terragrunt.hcl`. What this means is that depending on how you split the `infrastructure-live` repo, you may inadvertently update the path of the state file. You can fix this by doing a state migration to the new path, following https://github.com/gruntwork-io/knowledge-base/discussions/229 You may also want to take a look at https://github.com/gruntwork-io/terragrunt-infrastructure-modules-example#monorepo-vs-polyrepo to understand the tradeoffs between a monorepo setup and polyrepo setup.