Hacker News Reader

Comment by mattpallissard | Hacker News Reader

Fluff piece.

Here's a real snapshot. It’s terraform modules into one repo, terraform configuration into a separate one, the application in another, and helm configuration in yet another.

Opening 4 PRs, copy-pasting outputs of the first's CI run into the seconds yaml, shuffling secrets into vault, realizing you got the PR order wrong so you have to open a whitespace/noop PR to trigger the CI to run again.

All the while complaining that devs don't like to look at your house if cards let alone orchestrate a change without help and throwing artificial blockers up when solutions that would automate the process are proposed.

View on HN

I laughed cause that is what we are moving too. We currently have Infra terraform, Application terraform and application terraform modules (which are not shared) all in one repo.

How do you think it should be done?

One repo is better because you can basically include the entire change set in 1 PR / gitref.

Downside is it requires you come up with a structure and a bit of discipline to maintain coherence.

If you use codeowners and your CI can include other files, then most of the downsides go away, besides the repo size itself.

Multirepo is a bit easier to understand per item. You can have one single CI file, and don't need codeowners, but you move a lot of burden to test, deploy and run.

If your SCM supports codeowners and CI supports includes, I'd stick closer to mono-repos, and only break out things when it's helpful a D you obviously wouldn't change together.

Think services rather than micro.

Not the original commenter, but our team has recently been dealing with this exact thing. It depends on the specifics of your use case, architecture, etc., but there is a lot of value in keeping application Terraform code in the same repo as your applications. The main benefit is that it's a simpler developer experience to make infrastructure changes related to their specific app. You can still have a big repo with a bunch of internal modules and core infrastructure code, but having the apps have their own infrastructure code can lead to developers having more autonomy in the DevOps process.

Reply on news.ycombinator.com