What a Pipeline Is
Getting a Pageturn change from Maya's keyboard to live readers isn't one automated step — it's several, and they have to happen in order. The code has to be built, then tested, then packaged up, then put on the server. Doing each one separately, by hand, would bring back every problem from the last topic.
So you chain the steps together. When you line up automated steps — build, then test, then package, then deploy — and let each one trigger the next, you have a pipeline. A change goes in one end, travels the steps in a fixed order, and, if every step passes, comes out the other end live for users. One word, "pipeline," for that whole automated path.
What a pipeline is
A pipeline is a set of automated steps that run in a fixed order. Each step is sometimes called a stage. The order matters: you can't test code you haven't built yet, and you don't want to deploy code that hasn't been tested. The pipeline encodes that sequence once, so every change follows the same route from start to finish.
Think of an airport security line. There are fixed stations in a set order — show your ID, put your bag through the scanner, walk through the metal detector. You don't get to do them out of order, and everyone goes through the same stations. A pipeline is that idea for a code change. (Now drop the airport; we'll just say pipeline.)
Each stage is a gate
Here is the part people most often get wrong. Each stage is a gate, not just a step. If a stage fails — the build breaks, a test comes back red — the change stops right there. Nothing downstream runs. A change that fails the test stage is never packaged and never deployed.
This is exactly what you want. The whole reason to put tests before deploy is so that broken code is caught and held back before it can reach readers. A failed stage doesn't get skipped so the change can keep moving; it halts the line. Back at the airport: fail the security check and you don't proceed to the gate — you're stopped.
Triggered automatically
A pipeline usually starts on its own. A code change — Maya saving and sending up a new version — kicks it off, with no human pressing a "go" button. The change arriving is the signal; the pipeline wakes up and starts running its stages.
That automatic trigger is what makes the whole thing fast. Maya doesn't have to remember to run the steps, and nobody has to be at their desk for the change to be built and tested. The pipeline reacts to the change itself.
The same path every time
Because the stages are fixed and automated, every change travels the identical route. Maya's tiny typo fix and her big new feature go through the same build, the same tests, the same packaging, the same deploy. There's no "quick path" for small changes where a step quietly gets skipped.
That sameness is where the consistency from the last topic pays off at a larger scale. "Pipeline" is the backbone word for two of the biggest practices ahead — continuous integration (Chapter 4) and continuous delivery (Chapter 8) — and you'll build real ones, stage by stage, in the Git + GitHub Actions course.
- "A pipeline is a physical thing, like a network pipe." Nothing physical moves. It's a defined sequence of automated steps that a code change passes through — the word is just an analogy for that one-way flow from stage to stage, not a real pipe.
- "Pipelines are only about deploying." Deploy is usually just the last stage. A pipeline typically builds and tests and packages first — the deploy only happens if those earlier gates pass.
- "A failed step is skipped so the change keeps going." The opposite. A failed stage stops the line, and nothing downstream runs. That halting is the whole protective point of a gate.
- "Someone has to press a button to run it." A pipeline is normally triggered automatically by a code change. The change arriving is the signal that starts it; no human start is needed.
- "Pipeline" is the backbone term for CI/CD — continuous integration (Chapter 4) and continuous delivery (Chapter 8) are both pipelines.
- Almost every DevOps tool you'll meet either runs a pipeline or is a stage inside one, so the word unlocks a lot of later vocabulary.
- Understanding that a failed stage stops the line is what makes "the build is red, nothing's shipping" make sense in a real team.
- You'll build real pipelines stage by stage in the Git + GitHub Actions course; this is the picture those exercises assume you already have.
Knowledge Check
What is a pipeline, in software terms?
- A set of automated steps that run in a fixed order as a change passes through
- A physical pipe or cable that carries the software data between computers
- Only the final step that copies the finished app onto the production server
- A printed list of steps that a person reads and follows by hand during each release
A change fails the test stage of a pipeline. What happens next?
- The change stops there, and nothing downstream runs for it
- The failed test is skipped so the change can keep moving to deploy
- The change is deployed to users anyway, and the failure is logged for later
- The pipeline restarts from the very first stage and runs the change again
What usually starts a pipeline running?
- A code change arrives, and the pipeline is triggered automatically
- An operator must press a start button by hand for every single change
- It runs once a day at a fixed scheduled time, regardless of any changes
- It runs continuously in a loop even when no change has been made at all
You got correct