I tend to prefer infra code living separately from application deployment code. Multiple reasons for this:
- You want your infra team to make infra changes. You want your app team to make application changes (including application configuration). Putting them separately lets you specify separate guard rails on them (for example, only the infra team is allowed to push changes to your infra repo).
- You don't necessarily want to trigger a redeployment of the app if you make infra changes, and you rarely want to trigger a redeploy of your infrastructure if you trigger a new app build.
- You don't want a bad build of your app preventing you from making any infrastructure changes until it's fixed, and vice-versa.
It actually makes sense to put your app deployment code (i.e. Helm chart) inside the app repo itself.
Then, you can actually package up application config changes along with the corresponding release of your application. You also empower developers to do it themselves, without running the risk of breaking production more than they already can.
It will also allow your CI/CD tool to deploy both at once.
And since there's a strict mapping of app IaC and app itself in each GitHub branch, this actually lets you very easily create feature branch environments (i.e. a developer creates a new branch, your CI/CD picks it up, and automatically deploys it to a kube environment).
