This message was deleted.

@Andy Kelly have only ever done the later, which as you mention goes against DRY, but sometimes the copy/pasta approach is worth it for the separation (and the ease of which pipelines can be tailored/protected for each environment). FWIW, usually a shared/modules/mymodule is the approach we'd use for wrapping external modules, then the upgrade is contained to the module, and anything using that module in a stack (dev, staging) would just show it needs to be updated on the next run of a given pipeline (this may not help at all haha)

it certainly helps to see another view. Using Terraform Cloud with option 2 i don't have a unified pipeline which is one thing i don't like. So with say a container in a Gitlab pipeline i can see said container in a single pipeline going through the different stages. My IaC is different though i make the change to Dev and commit it. It triggers a run of the TF workspace for Dev. I apply it. I then make the change to QA, etc. i'd like to be able to have a unified view of my promotion from v1.1.0 to v1.2.0 of an infra module being applied across my environments. Our teams using option 1 have this by executing via Gitlab pipeline but then they don't have the security of separation i like Thanks for the input @Liam Baker

Hi, I try to go with the 1 option but I don’t really like multiple workspaces, I try to rely in my own modules in order to follow a DRY approach, just different var files. Additionally, you should take a look at terragrunt which is solving exactly the problem you describe https://terragrunt.gruntwork.io/

Like Jose we use terragrunt as well to manage that sprawl

Howdy! I have a bit of a different approach I've tried in addition to the ones above: Multiple AWS accounts for prod vs nonprod in combination to Option 1. I've created pipelines with Github Actions that would help promote/deploy from one env to another by only changing variable inputs and backends (when different aws accounts) PRs towards the default(main) branch automatically generates the plan and comments as a message in the pull request. It relies on AWS/GoogleCloud IAM Federation with Github Actions (https://awsteele.com/blog/2021/09/15/aws-federation-comes-to-github-actions.html) I found that it's cleaner to rely on TFVars if you don't want to see drifts, but that's ok to deviate the top-level terraform file if one ENV might have different resources. When selecting the correct env, I just make sure the

-var-file

points to the correct tfvar.

Guys thanks so much for the input. I've briefly looked at terragrunt a few years ago but never took it further, maybe now is the time. Having spoke to peers internal, external, this group and also a call with hashicorp today (renewal time) it seems this is a "problem" a lot of people are facing and no one standard has yet emerged. What I do know is that I'm not a massive fan of either of the current solutions we have internally. Lots of food for thought.