YAML pipelines in Azure DevOps basically won. The classic visual editor is mostly gone. If you're building pipelines in 2020, you're doing it in YAML. Here are the patterns that actually matter.
Template reuse and inheritance
Templates are where YAML pipelines shine. Define your common patterns once (build, test, deploy, security scan), then reference them from everywhere. You get step templates, job templates, parameterized. A platform team sets the standard structure. App teams extend it without copy-pasting boilerplate all day.
Environment and approvals
Azure DevOps Environments define deployment targets (Kubernetes namespaces, VM groups) with required approvals and deployment history. A pipeline stage that targets an environment requires approval from designated reviewers before proceeding. The deployment history on the environment shows what was deployed, when, and by whom. Environments replace the manual approval gates of classic release pipelines with a structured, auditable approval model.
Variable groups and Key Vault integration
Variable groups in Azure DevOps store environment-specific configuration that pipelines reference by name. Key Vault-backed variable groups link directly to Azure Key Vault: secrets in Key Vault appear as pipeline variables without storing them in Azure DevOps. The secrets are fetched at pipeline runtime; the Key Vault is the authoritative source. Rotating a Key Vault secret automatically updates the pipeline variable without any pipeline changes.
Service connections and least privilege
Service connections define the credentials pipelines use to deploy to Azure, Kubernetes, Docker registries, and other services. Each service connection should have only the permissions required for its pipeline: a connection for AKS deployments needs only namespace-level RBAC permissions, not cluster-admin. Separate service connections per environment (dev, staging, prod) ensure that a misconfigured dev pipeline cannot accidentally deploy to production.