Learning GitOps - FluxCD - History, Background & Why You Need GitOps

#Introduction

In episode 0 you prepared your entire environment: a Kubernetes cluster, kubectl, Helm, Kustomize, and the Flux CLI. Now it's time to step away from the terminal and understand why all those tools are needed. GitOps is not just a tool — it is an operating philosophy born from real pain in the world of application deployment.

This episode traces the history of GitOps: who created it, why Flux became the earliest project to realize it, and the concrete problems this mindset solves. Understanding this history matters because every FluxCD design decision in the following episodes — from the controller architecture to the way it reads Git — is an answer to the problems covered here.

#The Evolution of Application Deployment

Before GitOps, the deployment world went through a long journey that left plenty of scars.

#The Imperative, Manual Era

Deployment was originally done entirely by hand: SSH into a server, pull an image, start the process. The problems were obvious — no record of changes, no way to reproduce the same result, and a single typo could break production with no audit trail. Ask yourself: if your production server died today, could you rebuild it exactly as it was?

#The Infrastructure as Code Era

Enter the Infrastructure as Code (IaC) era: servers and pipelines defined as code. This was a huge step forward, but there was a gap: who executes that configuration? Usually a CI/CD pipeline running kubectl apply against the cluster. This gave rise to the term "config drift" — the configuration in Git no longer matches the actual state of the cluster, either because an unrecorded manual change was made, or because nobody verified what happened after apply.

The philosophical difference can be seen in the commands used in each era:

# The old way: a one-shot imperative command from CI
ssh deploy@prod "docker pull registry/myapp:1.2 && docker restart myapp"
 
# The GitOps way: change a value in Git, an in-cluster agent does the work
git add deploy/myapp.yaml
git commit -m "chore: update image myapp to 1.2"
git push origin main

Notice the last line: no SSH into servers, no kubectl apply from CI. All that happened was a change in Git — the rest is done by an agent running inside the cluster. This is the core of the paradigm shift from push to pull.

#The Birth of GitOps and Weaveworks

The turning point came in 2017. Weaveworks, a company building tools for Kubernetes, introduced the term GitOps to describe an operating pattern in which Git becomes the single source of truth for a deployment system. Before that name existed, Weaveworks had already built Flux v1 — a tool that continuously synchronizes a cluster with a Git repository — and this became the predecessor of the FluxCD we know today.

After the GitOps term gained popularity, the community formed the GitOps Working Group within CNCF to agree on its definition and principles. Around 2020+, the Flux project hit a second turning point: Flux v2 was completely redesigned with a modular architecture called the GitOps Toolkit. Flux v2 then entered the CNCF sandbox program and eventually graduated as one of CNCF's most mature projects.

Here's a brief timeline:

#The Four Core Principles of GitOps

GitOps stands on four community-defined principles. The entire FluxCD design follows them:

Compare this with the old way: kubectl apply once, then nothing watches it. GitOps does not stop after apply — it maintains the state forever.

The key phrase is pulled automatically. In a push architecture, cluster credentials must be carried to wherever CI runs — a huge leak potential. In the pull model, the agent inside the cluster holds the credentials, while Git merely provides configuration that is safe for anyone authorized to read. This is one reason GitOps is considered more secure by design, not just because it's a good habit.

The combination of these four principles produces an important guarantee: no matter what happens to the cluster, as long as Git remains correct, the system will return to the declared state. This is the principle FluxCD enforces rigorously.

#Problems Solved by GitOps

Why do we need this pattern? Because the following problems occur all too often in teams using manual or CI-driven deployment:

• Configuration drift detection: differences between actual state and Git are detected and automatically corrected, instead of being left to accumulate.
• Elimination of manual deployment: no more "silent deploys" over SSH; all changes go through Git.
• Audit trail through Git: every change has a commit history — who, when, and what.
• Environment consistency: dev, staging, and production all follow the same configuration from the same repo.
• Simple disaster recovery: a new cluster just pulls from Git; no need to reconstruct from memory.
• Rollback capability: failures can be undone with git revert or by checking out a previous commit.

Notice the common pattern behind all these problems: they all arise because there is no single, living source of truth. GitOps closes that gap by making Git the sole authority, while giving teams the tools to enforce that authority automatically.

#Benefits for Teams and Organizations

From a practical standpoint, GitOps changes how teams work in six major ways:

• Git as the single source of truth: one repo becomes the answer to "what is running in production?"
• Increased security: cluster credentials don't need to live in CI — the in-cluster agent pulls the configuration, so no cluster tokens leak in pipelines.
• Faster deployments: teams can deploy many times a day through PRs, not through manual queues.
• Better collaboration: PR-based workflows create room for review and approval before changes land.
• Compliance and auditability: a complete trail of every change is automatically available from Git.
• Developer productivity: developers focus on the end result being described, not the sequence of deploy steps.

#Closing

Episode 1 lays the conceptual foundation of this series:

• History: GitOps was created by Weaveworks in 2017, born from Flux v1, and matured as Flux v2 in its GitOps Toolkit form.
• Core principles: declarative, versioned and immutable, pulled automatically, and continuously reconciled.
• Real problems: config drift, manual deploy, audit trail, environment consistency, disaster recovery, and rollback.
• Team benefits: single source of truth, security, speed, collaboration, compliance, and productivity.

In episode 2 we move to the architecture level: getting to know FluxCD v2, why it chose a modular controller-based architecture called the GitOps Toolkit, FluxCD vs ArgoCD comparisons, and the core components that make it up. See you in the next episode!