Almost every CI/CD system, regardless of vendor, is built from the same handful of concepts:
| Term | What it means |
|---|---|
| Trigger | The event that starts a pipeline run — a push, a pull request, a schedule, a manual click |
| Pipeline / Workflow | The whole automated process for one trigger, start to finish |
| Job | A unit of work within a pipeline, typically running on its own isolated machine/container |
| Step | One command or action within a job, run sequentially |
| Runner / Agent | The actual machine (often an ephemeral VM or container) that executes a job |
| Artifact | A file (or set of files) produced by one job and made available to later jobs or a later stage |
A pipeline is usually structured as a directed graph of jobs — some run in parallel (linting and unit tests don't depend on each other), some run sequentially because one genuinely needs another's output (you can't deploy an artifact that hasn't been built and tested yet). Getting this graph right is largely about identifying real dependencies versus habitual "just run it in order" sequencing — parallelizing independent jobs is one of the most effective ways to make a pipeline faster without cutting anything out of it.