jobs-steps

Jobs, steps, and tasks

What it is

The execution hierarchy of a pipeline. Azure Pipelines organizes work as stages → jobs → steps, although a simple pipeline can use an implicit stage or job. A step can run a script, checkout, a task, or a template. In GitHub Actions, the comparable hierarchy is workflow → jobs → steps; a step runs a script or an action.

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

• Stage — a logical phase, such as build, test, or deploy. Every pipeline has at least one stage, even when it is not declared.
• Job — the smallest schedulable unit. Its steps run sequentially on one agent. Jobs without dependencies can run in parallel when capacity is available.
• 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 cross job boundaries through artifacts (see build-artifact) or explicitly declared output variables referenced through dependencies. A normal variable set in one job is not automatically available to another job.

Exam notes

• Steps execute on an agent as part of a job; separate jobs can run on different agents or pools.
• strategy: matrix: gives parallel build variants (OS × config).
• GitHub Actions parallels: jobs, steps, runs-on:, if:, needs:.

Related

pipeline-yaml · agent-pool · build-artifact

📘 Source: Microsoft Learn — Specify jobs and stages, checked 2026-09-17.