Azure DevOps Pipelines#
Azure DevOps Pipelines uses YAML files stored in your repository to define build and deployment workflows. The pipeline model has three levels: stages contain jobs, jobs contain steps. This hierarchy maps directly to how you think about CI/CD – build stage, test stage, deploy-to-staging stage, deploy-to-production stage – with each stage containing one or more parallel jobs.
Pipeline Structure#
A complete pipeline in azure-pipelines.yml:
trigger:
branches:
include:
- main
- release/*
paths:
exclude:
- docs/**
- README.md
pool:
vmImage: 'ubuntu-latest'
variables:
- group: common-vars
- name: buildConfiguration
value: 'Release'
stages:
- stage: Build
jobs:
- job: BuildApp
steps:
- task: GoTool@0
inputs:
version: '1.22'
- script: |
go build -o $(Build.ArtifactStagingDirectory)/myapp ./cmd/myapp
displayName: 'Build binary'
- publish: $(Build.ArtifactStagingDirectory)
artifact: drop
- stage: Test
dependsOn: Build
jobs:
- job: UnitTests
steps:
- task: GoTool@0
inputs:
version: '1.22'
- script: go test ./... -v -coverprofile=coverage.out
displayName: 'Run tests'
- task: PublishCodeCoverageResults@2
inputs:
summaryFileLocation: coverage.out
codecoverageTool: 'Cobertura'
- stage: DeployStaging
dependsOn: Test
condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
jobs:
- deployment: DeployToStaging
environment: staging
strategy:
runOnce:
deploy:
steps:
- download: current
artifact: drop
- script: echo "Deploying to staging"
trigger controls which branches and paths trigger the pipeline. dependsOn creates stage ordering. condition adds logic – succeeded() checks the previous stage passed, and you can combine it with variable checks to restrict certain stages to specific branches.
