Someone merges a change. Argo CD applies it exactly as written. All resources reconcile.
The application is now broken, consistently and automatically.
Automation is a force multiplier. It multiplies good decisions and bad decisions.
What GitOps actually solves
GitOps is valuable because desired state is versioned, reviewed, and reconciled. You can see what should run and compare it with what is running. That is a major improvement over ad-hoc production changes.
But a valid manifest can still contain an unsafe readiness probe, a destructive database migration, an incorrect secret reference, or an image that fails a business-critical workflow.
A clean reconciliation result does not certify the application.
Four gates I would place around GitOps
- Before merge: lint and validate manifests; check policies, dangerous privileges, basic resource settings, and deployment dependencies.
- Before promotion: test the actual image digest in a representative environment and make sure the database and configuration changes are compatible.
- During rollout: verify service-level health; use canary or progressive delivery when the blast radius justifies it.
- After rollout: compare error rates, latency, and key customer transactions with a known baseline; define who can stop or revert the release.
A rollback can also be complicated by data changes. Reverting a Deployment is not necessarily a safe rollback of an irreversible database schema migration. Design forward-compatible migrations and a recovery path deliberately.
Don't let auto-sync hide broken ownership
Continuous reconciliation is useful, but make clear who owns production promotion and how an emergency fix is handled. If a hotfix is applied directly to the cluster without updating Git, your controller may undo it. That's often correct behavior—but surprising during an incident is dangerous.
Write a runbook covering emergency changes, pausing reconciliation when appropriate, reverting Git, and validating user-facing recovery.
How to audit your own process
Choose a simulated bad change and ask: Would review catch it? Would the deployment process stop it? Would monitoring detect it? Could the team mitigate it in minutes?
You don't need a complex deployment platform to run this exercise. You need to know which safety barriers exist and which are assumed.
Discussion: Has GitOps made your production deployments safer—or just more consistent?
For release controls, GitLab pipelines, and Kubernetes deployment design, see GitLab CI/CD setup or request a discovery call.