Breaking It Down
A pipeline is not a single monolithic script. It is a structured hierarchy of work units, each with a specific scope and execution model. Understanding this hierarchy is essential for designing pipelines that are fast, maintainable, and debuggable.
The exact terminology varies by tool — GitLab CI calls them stages and jobs, GitHub Actions calls them jobs and steps, Jenkins uses stages and steps — but the underlying model is universal.
1. Pipeline
The top-level entity. It represents the entire automated journey from a code commit to a deployed artifact. A pipeline is typically triggered by an event: a push to a branch, a pull request being opened, or a scheduled timer.
2. Stages
Major sequential phases within a pipeline. A typical progression is Build → Test → Deploy. Stages enforce ordering: the Test stage will not begin until every job in the Build stage has completed successfully. If any stage fails, the pipeline halts at that point and does not proceed to later stages. This is the "fail fast" principle — you don't waste time deploying code that didn't even compile.
3. Jobs
The individual units of work within a stage. Jobs in the same stage typically run in parallel to reduce total pipeline duration. For example, within a Test stage you might have a "Unit Tests" job and a "Linting" job running simultaneously. If either fails, the stage fails.
4. Steps (or Scripts)
The actual shell commands executed sequentially inside a single job. A Build job's steps might be: git checkout, then npm install, then npm run build. Steps within a job are always sequential — each must succeed before the next runs.
Why This Structure Matters
The parallel-within-stage, sequential-between-stages model is a deliberate trade-off. Running all jobs sequentially would be simpler to reason about but would make pipelines painfully slow. Running everything in parallel would be fastest but would allow a deploy to start before tests finish. The stage model gives you a controlled execution graph: speed within a phase, safety between phases.
Senior engineers design stages around risk gates. Each stage boundary is a checkpoint. You only proceed to the next stage if the current one proves the code is safe enough to move forward. A common mistake is putting too many jobs in a single stage, which removes intermediate checkpoints and makes failures harder to diagnose.