Principle: Governance through git

[moshloop]

5. Governance through git

In the complex and adapative socio-technical system in which GitOps is most often applied, the process and decision making criteria that lead to a desired state, is often as or more important than the state itself.

[lloydchang]

The objective of GitOps is convergence to a declarative state.

While Git facilitates GitOps, Git is optional.

This relates to https://github.com/gitops-working-group/gitops-working-group/discussions/76#discussioncomment-633924

Thank you @moshloop @o6uoq

[moshloop]

This might be better phrased as *Governenace through pull/merge request" - Just applying changes into a state store isn't enough, the rationale, policy and signals that led to a state change being committed are as important (or even more) than the current desired state

[scottrigby]

I personally agree with your statement above. However I believe this is an extension of principle 2 in the revised principles draft – of which auditability is one benefit, and audit requirements are an implementation detail:

2. The principle of immutable desired state versions

   Desired State is stored in a way that supports versioning, immutability of versions, and retains a complete version history.

I would suggest that statements like this be proposed as part of the extended notes for principle 2.

[lloydchang]

This relates to gitops-working-group/gitops-working-group#48 (comment)

[moshloop]

I don't agree - If I push straight to master, and never rewrite history I still have immutable desired state versions.

It is not only the desired state that needs to be immutable but also the decision-making process that should a) be recorded and b) immutable

[lloydchang]

@moshloop That seems onerous. Heroku and Flagger allow git push without any merge requests nor pull requests at all; I consider them as GitOps.