The Breaking Point
We had a "deployment committee" that met every Wednesday. Not joking. Four engineers, two managers, and someone from QA would review what was "ready" for production. The actual deployment took 3 hours with manual kubectl commands, followed by anxious monitoring.
Feature branches lived for weeks. Merge conflicts were brutal. Nobody wanted to be the one deploying on Friday.
Then we adopted GitOps, and within six months, we were deploying 40+ times per week with fewer incidents than before. Here's how.
The Core Principle That Changes Everything
GitOps isn't just "put your YAML in Git." It's a fundamental shift in how you think about deployments.
Traditional deployment: I run a command that changes production. My laptop, my credentials, my responsibility.
GitOps deployment: I propose a change in Git. If approved, a system automatically reconciles production to match Git. The system is responsible, auditable, and reversible.
This distinction matters more than any specific tool choice.
Why ArgoCD Won for Us
We evaluated FluxCD and ArgoCD. Both are excellent. We chose ArgoCD for three reasons.
The UI provides visibility non-engineers can understand. When product managers ask "is the feature live?", they can check themselves.
Application-centric model matched our team structure. Each team owns their Application resources, not cluster-wide configuration.
Sync windows let us restrict when production changes can happen. Changes merged at 2 AM don't deploy until business hours.
The Repository Structure That Works
We tried monorepo. We tried one-repo-per-app. Neither worked well at scale. Here's what did:
Infrastructure repo: Contains cluster-level configuration, operators, monitoring setup. Managed by platform team. Changes require platform team approval.
Application repos: Each team has one repo for all their applications. Contains Helm charts or Kustomize overlays. Teams have full autonomy over their namespace.
Config repo: Contains ArgoCD Application resources that point to app repos. Acts as the "registry" of what's deployed where.
This separation means teams can't accidentally break cluster infrastructure, but have full control over their applications.
Progressive Delivery Saved Us
The real unlock was combining ArgoCD with Argo Rollouts for progressive delivery. Instead of all-or-nothing deployments:
New version deploys to 10% of traffic. Metrics automatically checked (error rate, latency). If healthy, traffic shifts to 30%, then 50%, then 100%. If unhealthy at any stage, automatic rollback to previous version.
This removed the fear from deployments. Bad deploys get caught automatically with minimal customer impact. Teams deploy more frequently because the risk is contained.
Culture Change Mattered More Than Tools
The technical implementation took 6 weeks. The culture change took 6 months. Engineers accustomed to careful, infrequent releases needed to trust the system. Managers needed to stop requiring approval meetings.
What helped: celebrating fast rollbacks as successes, not failures. Showcasing features that shipped in hours, not weeks. Making deployment status visible and boring—just another thing the system handles.