GitOps in Practice: How ArgoCD Changed the Way I Ship Code

For most of my early Kubernetes work, deploying meant SSHing into a jump box, running kubectl apply -f, and watching pods restart while hoping nothing drifted from what was actually in the repo. GitOps with ArgoCD fixed the part of that workflow I didn't even realize was broken: the gap between "what's in Git" and "what's actually running."

The core idea

ArgoCD watches a Git repo of Kubernetes manifests (or Helm charts, or Kustomize overlays) and continuously reconciles the live cluster state to match it. Instead of pushing changes to the cluster, you push changes to Git, and ArgoCD pulls them. That one inversion — push vs. pull — is the whole trick, and it has bigger consequences than it sounds like.

What actually changed for me

Drift became visible, not silent. Before ArgoCD, someone could kubectl edit a deployment in prod to hotfix something, and that change would just live there, invisible, until the next full redeploy wiped it out. ArgoCD's diff view shows exactly when the cluster has drifted from Git, and it'll flag it as OutOfSync instead of pretending everything's fine.

Rollbacks became a git revert, not a fire drill. Every sync is tied to a commit SHA. Rolling back a bad deploy is reverting the manifest change and letting ArgoCD reconcile — no re-running a deploy script from a laptop at 11pm.

Reviews got real. Because the deployment is just YAML in a PR, infrastructure changes go through the same review process as application code. A second pair of eyes on a resource limit change or an ingress rule catches things that used to slip through.

Where it still hurts

ArgoCD doesn't magically solve secrets management — you still need something like Sealed Secrets or External Secrets Operator sitting alongside it, since you can't just commit plaintext secrets to the repo it's watching. And the learning curve for App-of-Apps patterns (managing many ArgoCD Applications from one root Application) took me longer to get comfortable with than the basic sync workflow did.

Takeaway

If your deploy process still involves a human running commands against a cluster, GitOps isn't a nice-to-have — it's the difference between "we know what's running" and "we hope we know what's running." ArgoCD was the tool that made that distinction concrete for me.