Code Organization recommendation

[gruntwork-support]

This message was extracted from a discussion that originally took place in Gruntwork Community Slack. Names and URLs have been removed where appropriate

From a customer

This is kind of an abstract, strategy question but here goes. With our refarch, we have a number of DRY violations (in particular, ecs-deploy-runner s in each account). Is it generally advisable to identify these things, then introduce a higher-level module (i.e. by wrapping the Gruntwork one) with all the commonality to reduce the size of the leaf terragrunt.hcl files?

So with the ecs-deploy-runner example, you might end up with a my-ecs-deploy-runner module which wraps it and then the terragrunt.hcl file in each account is just the vars that are different (e.g. the vpc id)

[gruntwork-support]

From a grunt

Hey person, I believe that’s a valid approach and I can suggest that you should build out your folder structure in a way that it makes it easy for you to understand and maintain. That’s the thing that matters here.

Have you done the Ref Arch using our guide, or did we deploy that for you? In the first case, I’d suggest that a good place to look for the structure we use currently is this.

[gruntwork-support]

From a customer

It was deployed for us, but it was kind of a beta version of 2.0

[gruntwork-support]

From a grunt

Aha! So I’d need to check with the SMEs if you change the ecs-deploy-runners structure, what aould be the implications. I’ll ask internally & update you as soon as I can!

[gruntwork-support]

From a customer

The reason I'm asking is just because we made a change to our deploy runner machine_user_git_info in the applier config and one of the accounts had a slightly different value (reviewer overlooked it!) which was just a bit inconvenient

Where basically all the accounts (bar shared) have pretty much identical terragrunt.hcl files for ecs-deploy-runner

[gruntwork-support]

From a grunt

Hello! So I did ask internally, and think you’re actually on the right path here!

So, if you were to abstract away the ecs-deploy-runner and put the common things between them in one place, so you only have to update them once, that is a good step forward.

The challenge might come as you update the ecs-deploy-runners, in case there’s some unnoticed bugs by the refactoring itself.

Something interesting to share - terragrunt is actually being updated so that we could re-architecture the infrastructure-live repo very soon, and it will be easier to avoid duplication like you’re having.

Have a read here gruntwork-io/terragrunt#1566 :slightly_smiling_face:

[gruntwork-support]

From a customer

Very cool; I'll keep an eye on this RFC