Day 77: The real pipeline shape
Putting CI and GitOps together correctly
A common mistake is having CI both build the image AND run kubectl/helm to deploy it — this reintroduces the push-based model GitOps is meant to replace. The correct shape separates these cleanly:
- A developer merges a PR to main
- CI (Phase 14) builds a new image, runs security gates, and pushes it to a registry
- CI updates a manifest in the GitOps repo (e.g. bumping an image tag) and commits — this is the ONLY thing CI does that touches deployment state
- ArgoCD (running in-cluster) notices the Git change and syncs it to the cluster
Why the separation matters
CI never needs cluster credentials at all in this model — its only job is to update a Git repository. Every actual cluster change flows through ArgoCD's reconciliation, giving you one consistent audit trail (Git history) for every deployment, and one consistent enforcement point (self-heal) against drift.
The Four Questions: GitOps (ArgoCD)
Worked example for Docker: dependency hell → consistent runtime environments → VMs too heavy → shared kernel, weaker isolation. Apply it to GitOps: what problem (CI holding cluster-write credentials, undocumented manual changes) did it solve, why couldn't traditional push-based CI/CD solve it, and what trade-off (losing the 'quick manual fix' escape hatch, added reconciliation latency) does it introduce?
Phase 13 complete — you should now be able to
In a correctly separated CI/GitOps pipeline, what credentials does the CI system need to deploy a new version?
