Terraform + Continuous Deployment

Terraform HCP Terraform
,
1

Hi there,

I have been trying to make a decision on how to restructure a Terragrunt repository I have inherited. I want to simplifly and make things more resilient. I think moving Terraform Cloud will help but I have not used it extensively so far. I have been using the CLI workflow for years and I am now considering to introduce CD with Github Actions.

I can’t make my mind up on the number of repositories. In a CLI driven workflow, I always went for:

  • 1 repo per team (a team having it’s dedicated backend) for all stacks it manages (can be hundreds)
  • 1 repo per module with module version pinning in the stacks repo

In a VCS/API driven workflow, all the documentation/example that I have seen do have a single repo per stack. I find this has quite a lot of overhead and not necessarily easy to maintain at scale (duplicate the .github/workflow and other top level dot files once per stack=repo). And it feels like its going to be lots of clone/commits for some simple changes.

If you went to 1 stack per repo route, are you happy with your setup? How many stacks do you manage and how hard do you find it?

If you went for many stacks per repo route, I would love you to share some wisdom/experience. I am interested in how did you do it (logic in the runner? in the workflow? both?) and how you manage your CD limitations (triggering lots of job potentially per commit with change files filters).

Kind regards,
Matthieu

2

We have a repo per stack (i.e. per state file) plus a repo per module - in total a couple of hundred repos.

Yes there can be a lot of commits needed for some type of changes, but we use automation (Dependabot/Renovate) to help with some of that. We find this method much simpler to setup as you don’t need complex CI workflow scripts (especially if you want the ability to manually trigger a pipeline rerun - how does it know which stacks to run if there is no actual file change?) and version history is simple (it can be difficult to see what/how much changed between two commits quickly and step through changes).

1 Like