GitOps
GitOps applies declarative desired state, version control, and automated reconciliation to operations. A Git repository records what should run. A controller compares that desired state with the cluster and applies changes. This makes operational change reviewable, auditable, and reversible.
Pull-Based Delivery
Tools such as Argo CD commonly use a pull model: a controller inside or near the cluster watches Git and syncs declared resources. This reduces the need for external CI systems to hold broad cluster credentials. CI builds and publishes artifacts; GitOps changes the desired deployment state.
Drift
Drift is a first-class signal in GitOps. If someone changes production manually, the controller can report or correct the difference. Automatic correction is powerful but must be paired with break-glass procedures for emergencies.
Repository Design
Application source, infrastructure modules, and environment manifests can live together or separately. The best structure makes ownership and promotion clear. A repository layout that nobody understands is not GitOps; it is YAML archaeology.
Reconciliation Semantics
GitOps depends on a controller loop. The loop watches declared state, compares it with live state, and takes action according to sync policy. Automatic sync gives fast convergence but can surprise operators during emergencies. Manual sync gives more human control but may reintroduce queues. The right policy depends on environment criticality and team maturity.
Pruning is another important behavior. If a manifest is removed from Git, should the live object be deleted automatically? In a clean application namespace, pruning may be desirable. For shared resources or stateful systems, it can be dangerous without review.
Secrets and Git
GitOps does not mean putting plaintext secrets in Git. Common approaches include external secret operators, sealed secrets, encrypted files, or runtime references to secret managers. Each approach has tradeoffs around key rotation, auditability, disaster recovery, and developer ergonomics.
Example Promotion Flow
A CI pipeline builds image digest sha256:abc... and updates a staging manifest. The GitOps controller syncs staging. After checks pass, a promotion pull request updates the production manifest to the same digest. Reviewers inspect the exact artifact identity and environment diff. Production sync applies the change and reports health.
Study Task
Design a GitOps repository layout for three environments. Specify where image digests live, how promotion occurs, how secrets are referenced, who can approve production changes, and how emergency manual changes are reconciled afterward.
Operational Review
A GitOps review should compare desired state, live state, and organizational authority. Desired state should be readable in Git. Live state should be observable through the controller. Authority should be clear: who can merge, who can sync, who can pause reconciliation, and who can approve production promotion.
The review should also cover failure cases. What happens if the Git provider is unavailable? What happens if the controller applies a bad manifest? What happens if an operator makes an emergency change directly in the cluster? What happens if a secret reference cannot resolve?
GitOps is strongest when it makes normal change safe and emergency change accountable. It is weakest when repositories become unowned piles of generated YAML with no explanation of promotion, rollback, or ownership.