Stop 10 · Infrastructure as Code & AutomationTopics · 8/9

GitOps Basics

In short

What's actually running in your cluster right now? With GitOps, the answer is always "whatever is in the main branch", and a robot makes sure that stays true.

A practice where the desired state of infrastructure and deployments lives entirely in a Git repository, and automated tooling continuously syncs the real environment to match — Git becomes the single source of truth.

The blob character pins a colourful timetable on a notice board as a classmate looks on.

Think of it like this

The timetable on the notice board

The class timetable pinned on the notice board is the truth. If someone quietly swaps a period, the class monitor checks the board and puts it back. To really change a period, you get a new sheet approved and pinned.

Watch it happen

Git is the source of truth

Developer

Git repo

Argo CD

Cluster

merge: image 1.5

1/5You change the image tag in the deploy repo through a reviewed pull request.

The big ideas

What you need to know

Git is truth

Desired state lives in a repo. Every change is a commit with an author, a review and a history.

Pull, not push

An agent inside the cluster pulls changes. CI doesn't need cluster admin credentials.

Rollback is revert

Bad release? git revert the commit and the agent rolls the cluster back.

Tools

Argo CD and Flux are the two common GitOps tools, both CNCF graduated projects.

See it in code

Walk through the code

yaml

1apiVersion: argoproj.io/v1alpha12kind: Application3metadata:4  name: notes5  namespace: argocd6spec:7  project: default8  source:9    repoURL: https://github.com/you/notes-deploy10    targetRevision: main11    path: k8s/prod12  destination:13    server: https://kubernetes.default.svc14    namespace: notes15  syncPolicy:16    automated: { prune: true, selfHeal: true }

1/3Where the truth lives: a repo, a branch and a folder of manifests.

An Argo CD Application: "keep namespace notes matching k8s/prod on main". Apply it once; after that, Git drives everything.

Save yourself the pain

Common mistakes

Oops

Keeping app code and deploy manifests in one repo, so every code commit triggers a deploy.

Do this instead

Many teams use a separate deploy repo. CI builds the image, then opens a PR there to bump the tag.

Oops

Fixing a production issue with kubectl edit and moving on.

Do this instead

With self-heal it gets reverted. Commit the fix to Git so it sticks and is recorded.

Your mission

Watch drift get fixed

~45 min

Quick check

In GitOps, how do you roll back a bad deployment?

Go deeper

1Read a conceptual explanation of how a GitOps tool (like ArgoCD or Flux) continuously reconciles state.
2Learn why GitOps improves auditability: every change has a corresponding commit and history.
3Compare a traditional push-based deployment pipeline to a GitOps pull-based model.