Create Azure CI/CD Pipelines with YAML

This skill creates reliable, efficient, maintainable Azure DevOps CI/CD pipelines in YAML across the full Azure DevOps ecosystem - build agents, deployment strategies, security practices, and integration patterns. A pipeline foundation defines a trigger (branch include/exclude with path exclusions), variable groups plus individual variables, and clearly separated stages - a Build stage running a job on a specified VM image via a reusable step template, and a Deploy stage that depends on Build, runs only when the source branch is main, and deploys to an environment using a runOnce strategy. Multi-stage environment progression adds a BuildAndTest stage (build and test tasks with code coverage collection), a DeployDev stage gated on the develop branch using dev-specific variables and an Azure Web App deploy task, and a DeployProd stage gated on main using prod variables and a canary strategy that ramps traffic through 25%, 50%, and 100% increments via a parameterized deploy template.

Use it when building or hardening a full Azure DevOps CI/CD pipeline that needs multi-environment progression, security scanning, infrastructure deployment, and monitoring - not a single-stage build-only script. It is not meant to skip approvals: production deploys should route through deployment jobs tied to environments for proper tracking and sign-off, per the pipeline's own recommendations. Resource usage is meant to be bounded explicitly - Kubernetes CPU and memory requests and limits are set per job (for example, 500m CPU requested with a 1 CPU limit, and 1Gi memory requested with a 2Gi limit) - rather than left to defaults.

Given a project's build and deploy requirements, it produces reusable parameterized templates (a Docker build-and-push template taking image name, Dockerfile path, build context, and registry connection as parameters, tagging images with the build number and latest, and setting an output variable for the image tag), a security stage (SonarCloud analysis through prepare, build, analyze, and publish with a 300-second polling timeout, a quality-gate check, and a WhiteSource dependency scan), an infrastructure stage (installing Terraform 1.5.0, then running init against an Azure Resource Manager backend, plan against an environment-specific tfvars file, and apply from the saved plan), and a performance-tuned test job (4-way parallel execution, NuGet package caching keyed on the packages lock file with fallback restore keys, and a dotnet test run using all available CPUs while excluding integration tests).

trigger:
  branches:
    include:
    - main
    - develop
  paths:
    exclude:
    - docs/*
    - README.md

variables:
- group: 'shared-variables'
- name: buildConfiguration
  value: 'Release'
- name: vmImageName
  value: 'ubuntu-latest'

stages:
- stage: Build
  displayName: 'Build and Test'
  jobs:
  - job: BuildJob
    pool:
      vmImage: $(vmImageName)
    steps:
    - template: templates/build-steps.yml

- stage: Deploy
  displayName: 'Deploy to Environment'
  dependsOn: Build
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
  jobs:
  - deployment: DeployJob
    environment: 'production'
    strategy:
      runOnce:
        deploy:
          steps:
          - template: templates/deploy-steps.yml

Caching runs at two levels: a yarn.lock-keyed cache covering node_modules and the Yarn cache directory, and a separate commit-ref-slug-keyed cache for build output like dist/ and Next.js's .next/cache/, both set to a pull-push policy so every run can both read and refresh them. Pipeline health is monitored with a PowerShell step (conditioned to run always) that checks the agent's job status and, on a Failed status, posts a themed alert to a Teams webhook naming the build number and repository.

Platform and release engineers building Azure DevOps pipelines who need the full pattern set at once - variable groups for environment-specific config and secrets, branch-aware pipeline behavior, cross-project template reuse, comprehensive unit, integration, and security test stages, environment-gated deployment tasks for tracking and approvals, blue-green or canary deploys for production safety, dependency caching for speed, condition-driven flow control, infrastructure deployment folded into the same pipeline, and monitoring and alerting on pipeline health and deploy success.