Read on Twitter
Conceptually, I've found #GitOps to be a beneficial trend in #DevOps. At the same time i've found Git to be an odd fit for operations & delivery. Not technically, just a feeling. Technically, the fit couldn't be better: Git is immutable, versioned and easy to rollback.
Even more beneficial is the Git ecosystem which is rich with RBAC controls, approvals and visual audit trails from the likes of @github , @gitlab, @Bitbucket . The benefits of using Git are clear and if you think of Git as an immutable database then it completely makes sense...
Perhaps it was the fact that I've never used Git programmatically to "add" or "remove" rows but instead only through the Git CLI. After wrestling with the odd feeling of using Git in automated operations I became comfortable with it as a legitimate way forward.
But then yesterday we had our first #GitOps working group's 1st meeting. A proposed change to the principles is thinking beyond 'git' as the only storage mechanism. "... stored in repository that supports immutability, versioning and version history."
This makes the principles flexible enough to use other datastores which fit those requirements. Conceptually this also makes easier to consume if you too are wrestling with that odd feeling. But while this opens the scope...
I think Git remains the natural database choice for #GitOps for the reasons stated earlier even if it feels odd at first. You can learn more about the working group here: https://github.com/fluxcd/gitops-working-group
