GitOps deployment workflow
A Git-driven deployment pipeline where the cluster state is always a reflection of what's committed, not what someone ran manually.
The problem
When deployments happen through a mix of `kubectl apply`, CI scripts and manual fixes, nobody can say with confidence what's actually running versus what's in version control. GitOps closes that gap by making Git the single source of truth for cluster state.
Architecture
- Argo CD watching environment-specific Kustomize overlays in a deployment repository
- CI pipeline that builds, tests and pushes images, then updates the deployment repository
- Automated sync for lower environments, manual promotion gate for production
- Drift detection that flags any manual change made outside of Git
Technologies
Design decisions
Separate application and deployment repositories
Keeps application code review focused on the code, and deployment review focused on what's actually changing in the cluster.
Manual sync gate for production, automatic for staging
Balances deployment speed in lower environments against the need for a deliberate promotion step to production.
Lessons learned
- Drift detection is what makes GitOps trustworthy — without it, manual changes creep back in within weeks
- Splitting app and deployment repos adds overhead that's worth it once more than one service is involved
Working through something similar?
This lab reflects our own reference work, not a client engagement — but the approach transfers directly.
Start a technical conversation