#gitops (2024-04)
Discuss continuous delivery of infrastructure
Archive: https://archive.sweetops.com/gitops/
2024-04-05
:wave: How are folks doing gitops for Terraform, specifically promotion through environments? Previously terragrunt (because it was the closest thing to bare Terraform that could handle some orchestration) and the split repo approach. This was fine with Atlantis because split repo (live and modules) each env would be bumped to X.Y.Z release when ready. I’d like to do similar with a monorepo approach. git branches is a no go. Seen some folks automatically raising env + 1 PRs, so like main goes to dev, that then automatically raises a PR for the same change to test etc…not terrible but can see some downsides…any others…?
Seen some folks automatically raising env + 1
What I don’t like about this approach, is you don’t see the impact of the change across all enviroments when you make it. It’s left as a surprise env + 1 down the road.
Our approach, with GHA + Atmos, is to plan against all environments affected by the PR.
We store a planfile for each affected component (root module), and upon merge to main, we create an issue for each affected component. We then use “Issue Ops” to control when to roll out the changes to each environment. Using the commands on the issue, we control when to apply the planfile.
The challenge is there’s not always a dev-staging-prod flow. What about changes to accounts like audit, security, identity, etc. Accounts which are singletons. So the way to roll out changes, is not always deterministic.
dflook probably has the most popular GHAs for Terraform.
Our actions are documented here (we don’t use dflook)
https://atmos.tools/integrations/github-actions/
We also use a monorepo approach.
(hence our GHA for discovering what to plan/apply based on what was affected in the PR)
Currently using https://suzuki-shunsuke.github.io/tfcmt for an Atlantis style GHA workflow, doesn’t deal with env promotion in monorepo yet though.
and similar for CDK https://github.com/karlderkaefer/cdk-notifier
Are you considering general purpose CI/CD (e.g. GitHub, GitLab, CircleCi, et al) or specialized platforms (e.g. SaaS)
CLI tool to post AWS CDK diff as comment to Github pull request
I would avoid using comments. They are too noisy and spam every subscriber to the repo.
Instead, use job summaries.