Our workflow: Jenkins builds image → pushes to registry → operator runs helm upgrade → prays. GitOps flips the model: the Git repository describes the cluster state, Flux ensures the cluster matches. No imperative helm upgrade. Just git push.
Why GitOps¶
The problem: nobody knows what’s running on the cluster. Kubectl apply here, helm upgrade there, manual configmap edits. Configuration drift. The GitOps principle: what’s in git, runs. Always. Automatically. The agent reverts any manual change.
Bonuses: audit trail (git log), rollback = git revert, code review for infra changes (pull request), reproducibility (new cluster = git clone).
Flux vs. Argo CD¶
Argo CD: nicer UI, more features. Flux: lightweight, composable, better Helm integration. For 12 services with Helm charts, Flux won on simplicity.
Repository Structure¶
infrastructure/
├── base/ # Shared resources
├── environments/
│ ├── staging/ # Kustomize patches
│ └── production/
└── apps/
├── notification-service/
├── user-service/
└── ...
Workflow in Practice¶
- Developer pushes code → Jenkins builds image myapp:1.23.5
- Flux detects new tag in registry
- Flux updates manifest in git (image tag)
- Flux applies change to cluster
- Rollback? git revert commit → Flux applies previous state
Need help with implementation?
Our experts can help with design, implementation, and operations. From architecture to production.
Contact us