Learn GitOps with ArgoCD - History, Background & Why You Need GitOps

#Introduction

In episode 0 we prepared all the tools and verified them. Now it's time to step back from the keyboard and ask the single most important question: why does GitOps exist? Because before understanding a tool, we must first understand what problem it solves — and choosing a tool without understanding the problem is a fragile decision.

This episode is like reading history before buying a machine: once you know how painful manual deployment was and how fragile scripts are, you'll understand why the world moved to GitOps. In this episode we'll cover the evolution of deployment practices, the birth of the term GitOps by Weaveworks, the problems it solves, the four principles of GitOps, the push vs pull model comparison, and the benefits you can enjoy.

#The Evolution of Deployment Practices

The journey toward GitOps spans four eras, and each era was born as an answer to the pain of the previous one.

#Era 1: Manual Deployment

In the early days, deploying an application meant SSH-ing into the server, copying artifacts, running processes manually, then hoping everything worked. Each server was treated as an individual. There was no record of who changed what; everything depended on the memory and discipline of the person executing.

The problem is obvious: humans are inconsistent. One person forgets to change an environment config, another installs a different version, and there's not a single auditable trace. This is the root of many classic production failures.

#Era 2: Script-Based Deployment

As an answer, engineers started writing shell scripts to automate the sequence of deployment steps:

#!/bin/bash
set -euo pipefail
 
kubectl apply -f configmap.yaml
kubectl apply -f secret.yaml
kubectl set image deployment/api api=ghcr.io/arman/api:v1.2.0
kubectl rollout status deployment/api

This script is imperative: it spells out the step-by-step process to reach the end result. Better than manual, but fragile. kubectl set image overwrites state directly in the cluster, and if two people run different scripts at the same time, the end result is decided by whoever executed last — not by whoever was right.

#Era 3: CI/CD Pipelines

Next came CI/CD: Jenkins, GitLab CI, GitHub Actions, and friends automated build, test, and deploy. This was a huge leap — deployment became documented in pipelines, and failures could be detected immediately.

But there's an inherent structural weakness: the push model. Pipelines hold cluster credentials and push changes to production. The more pipelines, the more credentials spread around. And because deploys are driven from outside the cluster, it's hard to answer a simple question: "is the cluster actually in the state we want?"

#Era 4: Infrastructure as Code (IaC)

IaC declares infrastructure as code: terraform for cloud, kustomize and helm for Kubernetes. Now we can review infrastructure in pull requests and audit it through Git history. IaC solves how infrastructure is defined — but not yet how the changes reach and are maintained on the cluster.

#Era 5: The Birth of GitOps

That's where GitOps completes the puzzle: IaC provides the definition, Git provides the audit trail, and operators like ArgoCD provide the executor that continuously reconciles. Git becomes the single source of truth, and the cluster no longer waits for an external push — it pulls its own desired state from Git.

#What is GitOps?

The term GitOps was first coined by Weaveworks in 2017 as an operating model for Kubernetes: Git as the single source of truth for a declarative system, with an automated agent running inside the cluster that materializes and maintains that state.

In short: "what's in Git is the truth. The cluster must match Git. Always."

#Problems GitOps Solves

GitOps was born to solve real problems in the field:

#The Four Principles of GitOps

According to the Weaveworks definition, a truly GitOps system must satisfy four principles:

1. Declarative — the entire system is described as a desired end state, not a sequence of steps. The YAML manifests in Git are the only form of truth.
2. Versioned and immutable — every change is a new commit. Definitions are never changed "in place"; they're always revised and can be rolled back.
3. Automatically pulled — changes are fetched by an agent inside the cluster (pull model), not pushed by an external system holding credentials.
4. Continuously reconciled — the agent compares the actual state vs the desired state, then reconciles them automatically. If someone changes the cluster manually, the agent restores it.

#Push vs Pull Model

This difference determines the security and reliability architecture of your deployment:

The pull model is more secure because cluster credentials aren't spread externally, and more reliable because the cluster state is continuously forced back to the desired state.

#Benefits of GitOps

In short, here's what you get:

• Single source of truth — Git answers all questions about the system state.
• Better security — minimal cluster access.
• Faster deployment — PRs and review replace slow manual processes.
• Higher reliability — drift and human errors drop dramatically.
• Better collaboration — infrastructure is reviewed like application code.
• Disaster recovery — rebuild a cluster = re-sync from Git.
• Compliance and auditability — a complete record of who, what, when.

#Closing

This episode builds the conceptual foundation for the whole series:

• Deployment evolved from manual, to scripts, to CI/CD, to IaC, to GitOps.
• GitOps was coined by Weaveworks (2017): Git as the single source of truth.
• The main problems solved: drift, manual errors, audit, rollback, and visibility.
• Four principles: declarative, versioned, pulled, and continuously reconciled.
• The pull model is more secure and reliable than the push model.

Now you know why GitOps exists. In episode 2 we'll cover the GitOps ecosystem and an ArgoCD overview: the competitive landscape with Flux and Jenkins X, ArgoCD's component architecture, its core concepts, and how the reconciliation loop works. See you there!