Before writing a single line of YAML, you need a crystal-clear mental model of what a pipeline is, what problem it solves, and how its parts relate. This lesson builds that model.
The Problem: Manual Software Delivery
Imagine you're shipping a web application. Without automation, here's what happens every time you want to release a change:
This approach has predictable failure modes:
- Slow feedback — you don't know something's broken until days or weeks later
- Human error — forgot a step, deployed the wrong branch, misconfigured the server
- Fear of shipping — deployments become "events" instead of routine
- Bus factor — only one person knows the deployment ritual
The Solution: Automate the Entire Path
A CI/CD pipeline is an automated assembly line that takes your code from "pushed to Git" to "running in production" — with no manual steps.
Push
The Three Layers: CI, CD, CD
The term "CI/CD" actually contains three distinct concepts. Understanding the boundary between them is crucial for architectural decisions later.
| Layer | Question It Answers | Human Involvement | Frequency |
|---|---|---|---|
| CI | Is this code safe to merge? | Code review only | Every push/PR |
| CD (Delivery) | Can we ship this at any time? | Human clicks "Deploy" | Every merge to main |
| CD (Deployment) | Is this live in production? | None — fully automatic | Every merge to main |
Why This Matters: The DORA Metrics
Google's DORA research (10 years, 33,000+ professionals) proved that CI/CD directly predicts engineering team performance. These four metrics separate elite teams from the rest:
As a DevOps architect, you'll use these metrics to justify pipeline investments and measure whether your design decisions are working.
Anatomy of a Pipeline (The Map)
Every CI/CD pipeline, regardless of tool (GitHub Actions, GitLab CI, Jenkins), has the same anatomy. Once you internalise this structure, learning any specific tool becomes easy — it's just syntax for the same concepts.
The Five Core Concepts
| Concept | What It Is | Analogy |
|---|---|---|
| Trigger | The event that starts the pipeline | The "start" button on an assembly line |
| Pipeline / Workflow | The full automation definition (a YAML file) | The assembly line blueprint |
| Job | A unit of work that runs on one machine | A workstation on the line |
| Step | A single task within a job (shell command or action) | One operation at a workstation |
| Runner | The machine (VM) that executes a job | The worker at the station |
needs: to make one wait for another. Steps are always sequential within a job (same machine, shared filesystem).
Push-Based vs Pull-Based Delivery
As an architect, you'll need to decide between two fundamentally different delivery models. We'll go deep on both, but here's the map:
- CI pipeline pushes changes TO the cluster
kubectl applyorhelm upgradein pipeline- Pipeline needs cluster credentials
- Simpler to start with
- No drift detection
- Agent in cluster pulls desired state FROM Git
- ArgoCD/Flux watches Git, syncs to cluster
- Pipeline never touches the cluster
- More secure (agent is in-cluster)
- Automatic drift detection + correction
Since you already know Kubernetes, you intuitively understand "desired state reconciliation" — that's exactly what GitOps does for deployments. We'll cover both models and build toward GitOps with ArgoCD.
Where You're Headed
Here's the architecture you'll build over this learning series:
🧠 Recall Check
Without scrolling up, answer these:
- What are the three layers of CI/CD? What question does each answer?
- What's the difference between a job and a step?
- In push-based CD, who has cluster credentials — the pipeline or an in-cluster agent?
- Name the four DORA metrics.
Reveal answers
- CI ("Is our code healthy?"), Continuous Delivery ("Can we release at any time?" — human approves), Continuous Deployment ("Is this live?" — fully automatic)
- A job runs on one machine (runner) and can run in parallel with other jobs. A step is a single task inside a job — steps run sequentially, sharing a filesystem.
- The pipeline has cluster credentials in push-based CD. In pull-based (GitOps), only the in-cluster agent (ArgoCD) has them.
- Deployment frequency, Lead time for changes, Change failure rate, Mean time to recovery (MTTR)
🏋️ What's Next
In the next lesson, you'll write your first real GitHub Actions workflow and see it run. To prepare:
- Create a GitHub repository called
cicd-mastery(public is fine) - Clone it locally
- Create a
src/directory with any simple file (e.g., a "hello world" script) - Push it to GitHub
That's your lab environment for the rest of this series.