Azure Pipelines & CI
Stages/jobs/steps, triggers, fast feedback.
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.
# stage → job → step, all in one versioned YAML filestages:- stage: Buildjobs:- job: buildsteps:- script: npm ci && npm test # restore + test- script: npm run build- publish: $(Build.ArtifactStagingDirectory) # artifact for later stages- stage: DeployTestdependsOn: Buildjobs:- deployment: deployenvironment: 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.