In traditional CI/CD pipeline Jenkins pushes changes to the cluster. What if we flip the model? Git repository defines the desired state, and an operator in the cluster takes care of synchronization. This is GitOps.
The problem with push-based CI/CD¶
- CI server is a single point of failure
- Cluster credentials live outside the cluster
- Drift: someone changes cluster manually, CI doesn’t know
- Rollback: you have to trigger an old build
GitOps principles¶
1. Declarative description in Git. 2. Git as single source of truth. 3. Automatic synchronization. 4. Drift detection and reconciliation.
Flux in practice¶
Want to deploy a new version? Update the image tag in Git. Flux detects it and performs a rolling update. Rollback? Git revert. Audit trail? Git log.
Experience after 2 months¶
- Plus: complete audit trail, simple rollback, no credentials outside cluster
- Plus: drift detection
- Minus: slower feedback loop (1-3 min)
- Minus: merge conflicts in auto-generated commits
GitOps is CI/CD evolution¶
Auditable, reproducible, automated deployment. For us, a clear direction for the future.
gitopsfluxkubernetescd
Need help with implementation?
Our experts can help with design, implementation, and operations. From architecture to production.
Contact us