Jobs, steps, and tasks

What it is

The execution hierarchy of a pipeline. In Azure Pipelines a pipeline is made of stages → jobs → steps; each step is a task (or script/checkout). In GitHub Actions the equivalent is workflow → jobs → steps (steps call actions).

Why it exists

Breaking work into stages/jobs/steps gives control over where work runs (which pool), whether it runs (conditions/dependencies), and how output flows between phases.

Key ideas

  • Stages — major phases (build → deploy); jobs in a stage run in parallel by default.
  • Job — a unit that runs on a single agent; has its own pool, dependsOn, condition, strategy (matrix/parallel), continueOnError.
  • Step — the smallest unit of work: a built-in task (PublishPipelineArtifact, DotNetCoreCLI, CopyFiles), a script:/bash:/pwsh: block, or checkout.
  • Conditions (condition: succeeded(), failed(), always()) and variables gate/fan-out execution.
  • Outputs flow between jobs via artifacts (see build-artifact) or variable outputs (setVariable).

Exam notes

  • Only steps run on the agent; jobs may run on different agents/pools; stages are the top-level groups.
  • strategy: matrix: gives parallel build variants (OS × config).
  • GitHub Actions parallels: jobs, steps, runs-on:, if:, needs:.

pipeline-yaml · agent-pool · build-artifact

📘 Source: Microsoft Learn — Jobs Steps