Azure Pipelines Overview
Azure Pipelines is the CI/CD service within the Azure DevOps suite (alongside Boards, Repos, Artifacts, and Test Plans). It can build and deploy from Azure Repos or from external sources like GitHub, and it supports both classic UI-defined pipelines and the now-standard YAML-based approach where the pipeline lives as code in azure-pipelines.yml. A defining characteristic is its structural hierarchy: a pipeline contains one or more stages, each stage contains jobs, and each job contains steps — a slightly deeper nesting than tools like GitHub Actions, which is useful for modeling large enterprise release processes spanning multiple environments.
Cricket analogy: Like an IPL franchise's season, where the tournament (pipeline) has phases like the league and playoffs (stages), each phase has matches (jobs), and each match has overs (steps), letting Mumbai Indians plan an entire campaign methodically.
Stages, Jobs, and Steps
Stages typically represent major phases like Build, Test, and Deploy-to-Production, and can depend on one another or run conditionally. Jobs within a stage run on an agent — either a Microsoft-hosted agent (a fresh VM per run, with pools like ubuntu-latest or windows-latest) or a self-hosted agent registered by the organization. Steps are the individual tasks or scripts, and Azure Pipelines has an extensive built-in and marketplace task catalog (e.g. PublishBuildArtifacts@1, AzureWebApp@1) that wraps common operations as versioned, parameterized tasks rather than raw shell commands.
Cricket analogy: Like choosing between a fresh, ground-staff-prepared pitch for every match (Microsoft-hosted agent) versus the team's own practice ground they maintain themselves (self-hosted agent), while pre-approved fielding drills from the coaching manual replace players improvising routines.
trigger:
branches:
include:
- main
pool:
vmImage: 'ubuntu-latest'
stages:
- stage: Build
jobs:
- job: BuildApp
steps:
- task: UseDotNet@2
inputs:
version: '8.0.x'
- script: dotnet build --configuration Release
displayName: 'Build solution'
- task: PublishBuildArtifacts@1
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)'
ArtifactName: 'drop'
- stage: DeployProd
dependsOn: Build
condition: succeeded()
jobs:
- deployment: DeployWebApp
environment: 'production'
strategy:
runOnce:
deploy:
steps:
- task: AzureWebApp@1
inputs:
azureSubscription: 'prod-service-connection'
appName: 'my-prod-app'
Service Connections and Environments
Rather than embedding cloud credentials directly in pipeline variables, Azure Pipelines uses service connections — centrally managed, permission-scoped links to external systems like an Azure subscription, a container registry, or a third-party service. Deployment jobs also target Environments, which are trackable resources (an App Service, a Kubernetes namespace, a VM group) that record deployment history and can enforce approval checks before a deployment job is allowed to proceed, similar in spirit to GitHub Actions' environment protection rules.
Cricket analogy: Like a board-issued accreditation card that grants a player scoped access to the dugout and nets, rather than the stadium master key, while a match referee must approve the toss result before play officially proceeds.
Azure Pipelines' dependsOn and condition fields on stages let you build pipelines that only deploy to production if an earlier stage succeeded and a specific branch or manual approval condition is met — useful for modeling regulated, multi-environment rollout processes.
Microsoft-hosted agents are ephemeral and rebuilt for every job, so caching across runs requires the Cache@2 task or a pipeline artifact — assuming tool installs or dependencies will persist between runs is a frequent source of slow or flaky pipelines.
- Azure Pipelines is the CI/CD component of Azure DevOps and supports YAML-as-code pipelines.
- The hierarchy is pipeline → stages → jobs → steps, useful for modeling multi-environment releases.
- Jobs run on Microsoft-hosted agents (ephemeral VMs) or self-hosted agents registered by the org.
- Marketplace and built-in tasks (e.g.
AzureWebApp@1) wrap common operations as reusable, versioned units. - Service connections securely manage credentials to external systems instead of embedding secrets in YAML.
- Environments track deployment history and can enforce manual approval checks before deployment jobs run.
Practice what you learned
1. What is the structural hierarchy of an Azure Pipelines YAML pipeline?
2. What is a Microsoft-hosted agent?
3. What is the purpose of a service connection in Azure Pipelines?
4. How can a deployment stage be configured to require manual sign-off before running?
5. Why must caching be explicitly configured on Microsoft-hosted agents?
Was this page helpful?
You May Also Like
GitLab CI Basics
An introduction to GitLab CI/CD, its `.gitlab-ci.yml` configuration file, stages, jobs, and the GitLab Runner execution model.
CircleCI Fundamentals
Core concepts of CircleCI — the config.yml structure, orbs, workflows, and executors — for teams evaluating or already using the platform.
Designing Multi-Stage Pipelines
Learn how to structure a CI/CD pipeline into logical stages — build, test, package, deploy — so failures surface early and each stage has a clear contract with the next.
The CI/CD Tooling Landscape
A survey of the major CI/CD platforms — GitHub Actions, GitLab CI, Jenkins, CircleCI, and Azure Pipelines — and how their hosting model, configuration approach, and ecosystem differ.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics