CI/CD Course
CI/CD Pipeline Overview
In this lesson
A CI/CD pipeline is the automated assembly line that moves code from a developer's commit to running software in production. It is not a single script — it is a sequence of stages, each with a specific job, each acting as a gate that code must pass before advancing. Fail at any stage and the pipeline stops. Nothing broken moves forward. The pipeline is the enforcement mechanism for every quality standard a team cares about, written down once in code and applied consistently to every change, forever.
Lessons 4 through 7 covered what CI and CD each do individually. This lesson assembles the full picture — every stage in order, what triggers each one, where decisions get made, and the design principles that separate pipelines that teams trust from pipelines that teams route around. Think of this as the map you carry into every practical lesson from here on.
The Full Pipeline — All Eight Stages
A mature CI/CD pipeline has eight stages. Not every team needs all eight on day one — a small product might start with four — but understanding all eight tells you both what you are building toward and why each stage earns its place in the sequence.
The Eight-Stage Pipeline
Each Stage in Detail
Knowing the stage names is not enough — you need to know what each stage is actually doing, what it is looking for, and what it means when it fails. Here is the full breakdown.
Stage-by-Stage Reference
Parallel Stages: Where Speed Hides
A naive pipeline runs every stage sequentially — one finishes, the next begins. A well-designed pipeline finds every stage that does not depend on another and runs them simultaneously. This is where teams cut pipeline time from 20 minutes to 8 minutes without removing a single check.
Unit tests and static analysis have no dependency on each other. Both need only the compiled build output — so they can run in parallel. Integration tests against a test database can run in a separate job while end-to-end UI tests run in another. Security scanning does not need test results. Running these concurrently is not cutting corners — it is applying basic engineering logic to the pipeline itself.
The Airport Security Analogy
An airport with one security lane makes every passenger wait regardless of how many officers are available. Open six lanes in parallel and the queue moves six times faster — but every passenger still goes through exactly the same checks. A well-designed CI pipeline works the same way: parallelise the stages that have no dependency on each other, and the total pipeline time drops dramatically without sacrificing a single quality gate. The checks do not change. The queue does.
Pipeline Design Principles
A pipeline that technically works is not the same as a pipeline that teams trust. The difference comes down to a handful of design principles. Break any of them and you get a pipeline that is slow, flaky, inconsistent, or quietly ignored — which is the worst outcome of all.
Five Principles of a Well-Designed Pipeline
Warning: A Pipeline Nobody Looks at Is Worse Than No Pipeline
The most dangerous pipeline is one that runs, produces results, and gets ignored. It happens gradually — a flaky test gets muted, a failure notification gets turned off, someone bypasses the gate "just this once," and over six months the pipeline becomes wallpaper. The team still calls it CI/CD. It is not. It is a very expensive cron job. A pipeline only has value while the team treats a red build as an emergency. The moment that stops, the pipeline stops working — regardless of what the dashboard says.
Key Takeaways from This Lesson
Teacher's Note
Draw your team's current pipeline on a whiteboard. Label each box with how long it takes. You will immediately see which stages to parallelise, which are missing entirely, and where the 45-minute CI run is actually hiding.
Practice Questions
Answer in your own words — then check against the expected answer.
1. Which pipeline stage marks the handoff from CI to CD — the point where a versioned, immutable artifact is created and pushed to a registry for promotion through environments?
2. What term describes a deployment where running the process twice produces the same result as running it once — a property that makes automated rollback and retry safe?
3. What is the term for a test that sometimes passes and sometimes fails on identical code — the type of test that, left unaddressed, causes developers to lose trust in the entire pipeline?
Lesson Quiz
1. A team's pipeline runs build → unit tests → static analysis sequentially, taking 18 minutes total. The build takes 3 minutes, unit tests 8 minutes, static analysis 7 minutes. What is the most impactful single change they can make?
2. A team has a test that fails intermittently with no code changes. Rather than fix it, they add a retry — if it fails, run it again automatically. Why is this the wrong response?
3. A team configures their CI/CD pipeline entirely through their CI platform's web UI. A new engineer changes a setting accidentally and nobody notices for a week. What design principle would have prevented this?
Up Next · Lesson 9
Benefits of CI/CD
You have seen how the pipeline works. Now see what it actually changes — for engineers, for teams, for products, and for the organisations that ship them.