1. 1

    Part 1 — What is GitOps and why does it exist?

    If you’ve been running Kubernetes for a while, you’ve probably settled into a deployment workflow that looks something like this. A developer finishes a feature. CI builds and pushes a new image. Someone — maybe a…

  2. 2

    Part 2 — The four principles of GitOps

    GitOps gets thrown around a lot as a buzzword, which means it gets applied to a lot of things that aren’t quite it. “We store our manifests in Git” — not quite. “Our CI pipeline runs kubectl apply” — closer, but…

  3. 3

    Part 3 — ArgoCD: your first GitOps controller

    The last two posts covered the theory. GitOps is a good idea. The four principles make sense. Now let’s talk about the software that actually implements it. ArgoCD is the most widely used GitOps controller for…

  4. 4

    Part 4 — Structuring your Git repository

    Here’s a conversation that happens on almost every team adopting GitOps for the first time. You’ve got ArgoCD running, you’ve written your first Application, you’ve seen the sync work. Now someone asks: “where…

  5. 5

    Part 5 — Helm and Kustomize in a GitOps world

    By now you have a Git repo, ArgoCD watching it, and a folder structure that separates environments. The next problem is one that every team hits within the first week: your payments API in dev and your payments API…

  6. 6

    Part 6 — Secrets in a GitOps workflow

    Everything we’ve covered so far has a satisfying elegance to it. Desired state in Git. ArgoCD watching. Cluster reconciling. The whole system is auditable, reproducible, and self-healing. Then someone asks: “where do…

  7. 7

    Part 7 — Progressive delivery: beyond all-at-once deploys

    Rolling updates, which we covered back in the Kubernetes series, are a significant improvement over taking your service down to deploy a new version. But they have a blind spot: the moment the rollout completes, 100%…

  8. 8

    Part 8 — Running GitOps at scale: multi-cluster and multi-team

    Everything in this series so far has implicitly assumed a relatively simple setup: one team, one or a handful of clusters, one ArgoCD instance, a config repo with a reasonable number of applications. That setup works…