[jpdb]

And if you're pairing your infra-as-code with a gitops model then you can help prevent these kinds of issues with PRs.

You can also use your git history to restore the infrastructure itself. You may lose some data, but it's also possible to have destroyed resources retain their data or backup before destroy.

[zaphar]

The problem with infra-as-code and gitops is that it's often nearly impossible to tell what will actually happen with a PR without running it somewhere. Which is 1. expensive. and 2. nearly impossible to get to mirror production.

Production and staging are the farthest you can get from pure immutable environment that you can get. They carry state around all over the place. It's their entire reason for existing in some sense.

This means that while git-ops can be helpful in some ways it can also be incredibly dangerous in others. I'm not entirely sure it doesn't all come out in the wash in the end.

[zzyzxd]

GitOps is just like "DevOps" -- you don't really know what it means to a specific org until you talk to them, because people interpret it differently based on their own understanding (or if they have a horse in this race).

To me it always means describing the desired state of your infra in structured data, storing that in git, and run controller to reconcile it against the actual infra.

If your GitOps engine has to compile/run the "code" to uncover the desired state, that defeats the purpose of GitOps and is no better than running your hand crafted release bash script in a CI/CD pipeline.

It should have never been called infra-as-code, but infra-as-data.

See "The Rendered Manifests Pattern": https://akuity.io/blog/the-rendered-manifests-pattern/

[jansommer]

Yes, and usually you can make rules that prevent databases from being deleted again from IaC.