Azure DevOps YAML Pipelines: The Complete Enterprise Guide
Multi-stage YAML pipelines, variable groups, environments, approval gates, and template libraries — everything you need to build production-grade Azure DevOps pipelines.
Why YAML Pipelines Over Classic Pipelines
Classic Azure DevOps pipelines are configured through a GUI — which means configuration drift, no code review, no version history, and no reuse. YAML pipelines store your entire CI/CD definition as code alongside your application, reviewed in pull requests, versioned in Git, and reusable across projects via template libraries.
At VFL Technologies, we migrated all client pipelines to YAML in 2022 and have not looked back. Every enterprise .NET and Azure project we build now starts with a YAML pipeline skeleton on day one.
Multi-Stage Pipeline Structure
A production pipeline has at minimum three stages: Build, Deploy to Staging, Deploy to Production. Each stage runs sequentially with an optional approval gate between Staging and Production.
The Build stage compiles, runs unit tests, publishes code coverage, and produces a build artifact. The Staging stage deploys the artifact to your Azure App Service or AKS staging slot and runs integration tests. The Production stage deploys to production — but only after a manual approval from a designated approver configured in Azure DevOps Environments.
Variable Groups and Key Vault Integration
Never hard-code secrets in YAML. Use Variable Groups in Azure DevOps Library, backed by Azure Key Vault. Link a Key Vault to a Variable Group — every secret in the vault is automatically available as a pipeline variable, rotated automatically, and audited.
Use pipeline variables for non-secret configuration (environment names, resource group names) and Key Vault-backed Variable Groups for connection strings, API keys, and certificates. This separation means your YAML pipeline file contains zero sensitive values and can be fully public in your repository.
Reusable Pipeline Templates
The most powerful feature of YAML pipelines is template references. Create a separate repository (pipeline-templates) containing your organisation's standard build, test, and deploy jobs as template files. Any pipeline in any project can reference these templates with a single line.
When you update a template — adding a security scanning step, updating a tool version — every pipeline that references it picks up the change on next run. This is how enterprise DevOps teams enforce standards across 50+ repositories without maintaining 50 separate pipeline files.
Environments and Approval Gates
Azure DevOps Environments are the mechanism for controlling deployment to sensitive targets. Create environments for Staging and Production, then configure approvals: a deployment to Production requires approval from a member of the Release Approvers group before it proceeds.
Combine approvals with deployment gates — automated checks that must pass before deployment continues. Gates can query Azure Monitor for active alerts, check a work item query for open P1 bugs, or call a REST endpoint on your change management system. This gives you automated compliance at the pipeline level, not just in documentation.