Azure Pipelines & CI

Stages/jobs/steps, triggers, fast feedback.

Beginner30 min · lesson 1 of 15

Azure Pipelines is the automation engine of Azure DevOps — the service that builds, tests, and deploys your code. Understanding its structure and how continuous integration works is the foundation of everything a DevOps engineer does on Azure.

The pipeline hierarchy

A pipeline is organized into stages, which contain jobs, which contain steps that run individual tasks on an agent. Stages let you separate concerns — a build stage, then a deploy-to-test stage, then deploy-to-prod — and can have dependencies and gates between them. Jobs within a stage can run in parallel on different agents. Steps are the actual commands: restore dependencies, compile, run tests, publish artifacts. This structure means one YAML file can express your entire build-and-release flow, from a code push all the way to production, as reviewable code rather than clicks in a UI.

the pipeline structure
# stage → job → step, all in one versioned YAML file
stages:
- stage: Build
jobs:
- job: build
steps:
- script: npm ci && npm test # restore + test
- script: npm run build
- publish: $(Build.ArtifactStagingDirectory) # artifact for later stages
- stage: DeployTest
dependsOn: Build
jobs:
- deployment: deploy
environment: test # gates/approvals attach here

Continuous integration

Continuous integration means the pipeline runs automatically on every code change — a trigger on push to a branch (or on a pull request) kicks off the build so problems are caught within minutes, not at release time. A good CI pipeline is fast and reliable: it restores dependencies (with caching to avoid re-downloading), compiles, runs the test suite, and fails the build if anything breaks, giving developers quick feedback on every commit. This fast feedback loop is what keeps the codebase always in a buildable, tested state and lets teams integrate frequently rather than enduring painful big-bang merges. Speed and trust matter — a slow or flaky pipeline gets ignored or bypassed.

The CI flow
1push / PR trigger
runs on every change
2restore + build
with dependency caching
3run tests
fail fast on regressions
4publish artifact
output for deploy stages
CI runs automatically on every change: build, test, and publish. Fast, reliable feedback keeps the codebase always shippable.
A slow or flaky pipeline gets bypassed
If CI takes too long or fails randomly, developers stop trusting it and route around it — merging without waiting or disabling checks. Invest in pipeline speed (caching, parallel jobs) and reliability (fix flaky tests), because a fast, trustworthy pipeline is the one that actually protects the codebase.