Introduction
A pipeline, in the DevOps sense, is an automated sequence of stages that a code change passes through on its way from a developer's commit to a running system, with each stage performing one job such as building, testing, or deploying. Stages run in a defined order, and a pipeline typically stops immediately if a stage fails, preventing broken code from reaching later stages like production deployment.
Cricket analogy: A player's development pathway runs through fixed stages in order, from academy trials to age-group squads to first-team selection, and a failure at any stage halts progress rather than letting an unready player skip ahead, mirroring how a pipeline stops at the first failing stage.
Explanation
Most pipelines are defined declaratively in a configuration file checked into the same repository as the code, describing each stage as a list of steps and the conditions that trigger the pipeline, commonly a push or a pull request. This makes the pipeline itself version-controlled and reviewable like any other code, so changes to how software is built or tested go through the same review process as the software itself.
Cricket analogy: A club writes its training and selection criteria down in an official handbook that gets reviewed and updated by the coaching committee, rather than leaving it as unwritten habit, mirroring how a pipeline's stages are defined in a version-controlled file anyone can review.
Pipelines can run stages sequentially or in parallel: independent checks like linting, unit tests, and security scans often run at the same time to save wall-clock time, while stages with real dependencies, such as deploying only after tests pass, must run in order. Well-designed pipelines also cache dependencies and reuse build artifacts between stages so the same work is not repeated unnecessarily.
Cricket analogy: A team can run fitness testing, video analysis, and equipment fitting for new signings all at once since they don't depend on each other, but selection for the match squad must wait until all of them are done, mirroring how independent pipeline stages run in parallel while dependent ones run in order.
Example
stages:
- name: lint
parallel: true
- name: unit-tests
parallel: true
- name: security-scan
parallel: true
- name: build # runs after lint/tests/scan all pass
depends_on: [lint, unit-tests, security-scan]
- name: deploy
depends_on: [build]Key Takeaways
- A pipeline is an ordered sequence of automated stages a code change passes through.
- A failing stage stops the pipeline, preventing broken code from reaching later stages like deploy.
- Pipelines are usually defined declaratively in a version-controlled config file.
- Independent stages can run in parallel; dependent stages must run in sequence.
Practice what you learned
1. What happens when a stage in a pipeline fails?
2. Where is a pipeline's configuration usually defined?
3. Which stages are good candidates to run in parallel?
4. What common event triggers a pipeline to run?
5. Why must a deploy stage typically run after the test stage rather than in parallel with it?
Was this page helpful?
You May Also Like
CI vs CD
The difference between Continuous Integration, which merges and validates code constantly, and Continuous Delivery or Deployment, which automates getting it to production.
DevOps Lifecycle
How the DevOps lifecycle chains Plan, Code, Build, Test, Release, Deploy, Operate, and Monitor into one continuous, automated feedback loop.
What Is Docker
What Docker is and how it packages an application with its dependencies into a portable container that runs consistently across environments.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics