GitOps

GitOps: Your Code’s Personal Butler 🎩

Imagine you have a magical butler who keeps your room exactly the way you want it. You write down “I want my toys on the shelf, books on the desk, and bed made” on a special note. The butler reads that note every day and makes sure your room matches it perfectly!

GitOps is that magical butler for your software.

The Big Picture: What is GitOps?

Think of your favorite video game. When you save your game, it remembers exactly where you are, what items you have, and what level you’re on. GitOps works the same way for apps!

GitOps = Git (your save file) + Ops (operations/running things)

Instead of someone manually clicking buttons to put your app online, GitOps reads a “save file” (stored in Git) and automatically makes your app match that save file.

graph TD
    A["📝 You Write Config"] --> B["💾 Save to Git"]
    B --> C["🤖 GitOps Tool Reads It"]
    C --> D["🚀 App Matches Your Config"]
    D --> E["✅ Everything is Perfect!"]

GitOps Principles: The Golden Rules

Just like a game has rules, GitOps has special rules that make it work like magic.

Rule 1: Everything Lives in Git

Remember how your game saves everything to one save file? GitOps does the same thing!

Example:

# my-app-config.yaml
app: my-cool-website
replicas: 3
memory: 512MB

This file lives in Git. If someone asks “what’s running?”, you show them this file. No secrets, no mystery!

Rule 2: Git is the Single Source of Truth

Imagine two kids arguing about the rules of a game. “I have 5 lives!” “No, you have 3!”

In GitOps, there’s no argument. Whatever Git says is TRUE. Period.

Real Life:

• Git says “run 3 copies of the app” → You run 3 copies
• Git says “use version 2.0” → You use version 2.0
• No exceptions!

Rule 3: Changes Go Through Git Only

Want to change something? You MUST update the file in Git first. No sneaky shortcuts!

Wrong way: Manually changing settings on a server Right way: Update the file in Git, let GitOps do the work

Rule 4: Automatic Self-Healing

If something breaks or someone messes with your app, the GitOps butler notices and fixes it automatically!

graph TD
    A["😱 Someone Deleted a Server!"] --> B["🔍 GitOps Notices"]
    B --> C["📖 Reads Git Config"]
    C --> D[🔧 Rebuilds What's Missing]
    D --> E["😌 Everything Works Again!"]

GitOps Workflow: How the Magic Happens

Let’s follow a change from start to finish!

Step 1: Developer Makes a Change

Sarah wants to add a new feature. She writes code and updates the configuration file.

Step 2: Code Review (Friends Check Your Work)

Just like asking a friend to check your homework, other developers review Sarah’s changes.

Step 3: Merge to Main Branch

Once approved, the changes join the “official” version in Git.

Step 4: GitOps Tool Detects Change

The magical butler (GitOps tool) notices: “Hey! The save file changed!”

Step 5: Apply Changes Automatically

The tool makes the real app match the new save file.

Step 6: Verify Everything Works

GitOps checks: “Does reality match the save file? Yes? Great!”

graph TD
    A["👩‍💻 Write Code"] --> B["📝 Update Config"]
    B --> C["👀 Team Reviews"]
    C --> D["✅ Approve & Merge"]
    D --> E["🤖 GitOps Detects"]
    E --> F["🚀 Deploy Automatically"]
    F --> G["🔍 Verify Success"]

Declarative Configuration: Describing What You Want

The Ice Cream Order Analogy

Imperative (Old Way): “Go to the freezer, open the door, reach to the second shelf, grab the chocolate container, get a scoop, put it in a cone…”

Declarative (GitOps Way): “I want one scoop of chocolate ice cream in a cone.”

You describe WHAT you want, not HOW to do it!

Real Example

Declarative Config:

# deployment.yaml
name: my-website
replicas: 3
image: myapp:v2.0
port: 8080

This says: “I want my website running 3 copies, using version 2.0, on port 8080.”

You don’t say: “First create a server, then download the code, then install dependencies, then…”

The GitOps tool figures out the “how” for you!

Why Declarative is Awesome

Desired State Management: The Perfect Room

Remember our butler analogy? Desired State is the note you write describing your perfect room.

Current State vs Desired State

Desired State (what you want):

replicas: 5
version: 2.0

Current State (what’s actually running):

• 3 replicas running
• version 1.9

GitOps sees the gap and fixes it!

graph TD
    A["📋 Desired State: 5 replicas"] --> C{🔍 Compare}
    B["💻 Current State: 3 replicas"] --> C
    C --> D["😮 Gap Found!"]
    D --> E["🔧 Add 2 More Replicas"]
    E --> F["✅ Now Matches!"]

Continuous Reconciliation

The GitOps butler doesn’t check once and go to sleep. It keeps checking forever!

Every few seconds: “Does reality match the save file? Yes? Good. No? Fix it!”

This means:

• Someone manually deletes a server? GitOps rebuilds it.
• Settings get changed? GitOps resets them.
• Your app always stays exactly as defined in Git.

Pull-Based Deployment: The Patient Waiter

Imagine a waiter who keeps checking on your table: “Need anything? Need anything? Need anything?”

That’s pull-based deployment!

How It Works

1. A GitOps tool (like ArgoCD) runs INSIDE your system
2. It constantly “pulls” (checks) Git for changes
3. When it finds changes, it applies them

graph TD
    A["📦 Git Repository"] --> B["🔄 GitOps Tool Checks"]
    B --> C{Changes Found?}
    C -->|Yes| D["📥 Pull Changes"]
    C -->|No| E["😴 Wait & Check Again"]
    D --> F["🚀 Apply to Cluster"]
    E --> B

Example: ArgoCD Pull-Based

# ArgoCD watches this repo
apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  source:
    repoURL: github.com/myteam/app
    path: deployments/
  destination:
    server: my-cluster

ArgoCD lives in your cluster and keeps asking Git: “Anything new? Anything new?”

Why Pull is Popular

• More Secure: Nothing outside can “push” into your system
• Firewall Friendly: Only outgoing connections needed
• Self-Healing: Tool runs inside, can fix things immediately

Push-Based Deployment: The Eager Messenger

Now imagine a messenger who runs to you the MOMENT something changes: “NEWS! NEWS! Changes are here!”

That’s push-based deployment!

How It Works

1. You make a change in Git
2. Git sends a signal (webhook) to a deployment tool
3. The tool immediately pushes changes to your system

graph TD
    A["👩‍💻 Push to Git"] --> B["🔔 Webhook Triggered"]
    B --> C["🤖 CI/CD Pipeline"]
    C --> D["📤 Push to Cluster"]
    D --> E["✅ Deployed!"]

Example: GitHub Actions Push

# .github/workflows/deploy.yml
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to Kubernetes
        run: kubectl apply -f deployment.yaml

When you push to main, GitHub immediately runs this and pushes to your cluster.

Pull vs Push: The Comparison

When to Use Which?

Use Pull when:

• Security is very important
• You want automatic self-healing
• Your cluster is behind a firewall

Use Push when:

• You need instant deployments
• Simple setup is priority
• You’re okay managing credentials

GitOps Tools: Your Butler Options

You’ve learned what a GitOps butler does. Now let’s meet the actual butlers!

ArgoCD 🐙

The most popular GitOps tool. Like a friendly octopus managing your apps!

What makes it special:

• Beautiful web dashboard
• Sees your apps visually
• Syncs with one click
• Great for Kubernetes

# ArgoCD Application
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  source:
    repoURL: https://github.com/me/app
    path: k8s/
  destination:
    server: https://kubernetes.default.svc

Flux 🔄

Another popular choice. Like a reliable robot that never sleeps!

What makes it special:

• Lightweight and fast
• Multi-cluster support
• Great automation
• CLI-focused

# Flux GitRepository
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: my-app
spec:
  url: https://github.com/me/app
  interval: 1m

Jenkins X 🤖

For teams who already love Jenkins. Like upgrading your old butler!

What makes it special:

• Familiar to Jenkins users
• Full CI/CD pipeline
• Preview environments

Comparing the Tools

Putting It All Together

Let’s see a complete GitOps story!

The Adventure of Deploying a New Feature

Chapter 1: The Developer Maya writes a new login page. She updates the config:

# deployment.yaml
image: myapp:v3.0  # New version!
replicas: 3

Chapter 2: The Review Her team checks the code. “Looks good! Approved!”

Chapter 3: The Merge Changes join the main branch in Git.

Chapter 4: The Butler Awakens ArgoCD notices: “The save file changed! v3.0 is new!”

Chapter 5: The Deployment ArgoCD pulls v3.0 and deploys it to all 3 replicas.

Chapter 6: The Happy Ending Users see the new login page. Maya celebrates!

graph TD
    A["🎨 Maya Codes v3.0"] --> B["📝 Updates Config"]
    B --> C["👥 Team Reviews"]
    C --> D["✅ Merged to Main"]
    D --> E["🤖 ArgoCD Detects"]
    E --> F["🚀 Deploys v3.0"]
    F --> G["🎉 Users Happy!"]

Key Takeaways

1. GitOps = Git as your source of truth - Everything is stored in Git

2. Declarative > Imperative - Describe what you want, not how to get it

3. Desired State Management - GitOps constantly makes reality match your config

4. Pull-Based - Tool checks Git and pulls changes (more secure)

5. Push-Based - Git triggers deployment (faster)

6. Tools - ArgoCD and Flux are the popular choices

You Did It! 🎉

You now understand GitOps! Think of it as:

“A magical butler that reads your wishlist from Git and makes sure your app always matches it, fixing anything that goes wrong along the way.”

Every time you push a change to Git, your trusty GitOps tool will:

• See the change
• Compare it to what’s running
• Fix any differences
• Keep checking forever

Welcome to the future of deployments! 🚀