YAML Templates

In this lesson we’ll cover YAML fundamentals and how to use YAML templates in Azure DevOps pipelines. Whether you are an experienced DevOps engineer, moving from development, or transitioning from systems administration, this guide will help you understand essential CI/CD pipeline design: starting from small pipelines and progressing to reusable templates that keep your configuration DRY (Don’t Repeat Yourself). Below are concise, practical examples and clear explanations that follow the original sequence.

What is YAML for pipelines?

YAML (YAML Ain’t Markup Language) is a human-friendly data serialization format used to describe Azure DevOps pipelines. A pipeline YAML defines what triggers a run, which agents execute jobs, and the ordered steps performed (build, test, publish, deploy, etc.). A full ASP.NET build-and-test pipeline example:

# ASP.NET
# Build and test ASP.NET projects.
# Add steps that publish symbols, save build artifacts, deploy, and more:
trigger:
- master

pool:
  vmImage: 'windows-latest'
  name: 'Default'

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'

steps:
- task: NuGetToolInstaller@1

- task: NuGetCommand@2
  inputs:
    restoreSolution: '$(solution)'

- task: VSBuild@1
  inputs:
    solution: '$(solution)'
    msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.binariesDirectory)\\"'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

- task: VSTest@2
  inputs:
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

We will begin with a much smaller pipeline and show how to extract repeated logic into templates.

Creating a new pipeline in Azure DevOps

When you create a pipeline in Azure DevOps, the wizard asks where your source code is hosted and offers a starter pipeline that you can customize.

A screenshot of the Azure DevOps "New pipeline" page asking "Where is your code?" with options like Azure Repos Git, Bitbucket Cloud, GitHub, and GitHub Enterprise Server shown. The left sidebar shows a project named KodeKloudData and pipeline-related navigation.

The Starter pipeline is a minimal YAML template you can evolve. Example starter pipeline:

# Starter pipeline
# Start with a minimal pipeline that you can customize to build and deploy your code.
# Add steps that build, run tests, deploy, and more:
trigger:
- master

pool:
  vmImage: windows-latest
  name: Default

steps:
- script: echo Hello, world!
  displayName: 'Run a one-line script'

- script: |
    echo Add other tasks to build, test, and deploy your project.
    echo See https://aka.ms/yaml
  displayName: 'Run a multi-line script'

trigger — branches or events that start the pipeline (example: pushes to master).
pool — selects the agent image the job runs on.
steps — executed sequentially; script steps run shell/cmd lines. Use displayName for readable step names in the pipeline UI.

Example trimmed run output for the one-line script:

Starting: Run a one-line script
============================================================
Task         : Command line
Description  : Run a command line script using Bash on Linux and macOS and cmd.exe on Windows
Version      : 2.244.3
Author       : Microsoft Corporation
Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/utility/command-line
============================================================
Generating script.
Script contents: shell
echo Hello, world!
========================== Starting Command Output ==========================
"C:\Windows\system32\cmd.exe" /D /E:ON /V:OFF /S /C "CALL "C:\Users\jeremy\Downloads\agent\_work\_temp\6f412fab-641c-4d74-b8b9-3facf56d4c57.cmd""
Hello, world!
Finishing: Run a one-line script

YAML structure: keys, lists, and nested dictionaries

YAML constructs are simple and consistent:

Key-value pairs (scalars): e.g., vmImage: ubuntu-latest
Lists: items prefixed with - under a parent key (e.g., entries under steps)
Nested dictionaries: keys with indented child keys (e.g., properties under pool)

Example showing nested dictionaries, lists, and variables:

trigger:
- master

pool:
  vmImage: ubuntu-latest
  name: Default
  person:
    name: Jeremy Morgan
    age: 47
    occupation: trainer

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'

steps:
- script: echo $(PipelineRunnerName)
  displayName: 'Run a one-line script'

- script: |
    echo Add other tasks to build, test, and deploy your project.
    echo See https://aka.ms/yaml
  displayName: 'Run a multi-line script'

Key points:

Lists use - and indentation attaches items to their parent key.
Scalars are often unquoted, but quote any string that could be misinterpreted (numbers, booleans, values with colon or leading zero).

Use quotes for strings that could be misinterpreted (for example, values that look like numbers or booleans, or values with special characters). This prevents surprising parsing behavior.

Quick reference table: common pipeline keys

Key	Purpose	Example
`trigger`	What causes runs (branches, PRs, paths)	`- master`
`pool`	Agent image or pool to run the job	`vmImage: 'windows-latest'`
`variables`	Reusable values referenced as `$(Name)`	`solution: '*/.sln'`
`steps`	Ordered operations inside a job	`- script: echo Hello`
`template`	Include external YAML fragments	`- template: 'nuget.yml'`

Variables in pipelines

Variables let you parameterize pipelines and avoid repeating values. Define at top-level with variables: and reference as $(VariableName). Example:

variables:
  PipelineRunnerName: 'Jeremy Morgan'
  PipelineRunnerAge: '47'

Use inside steps:

steps:
- script: echo $(PipelineRunnerName)
  displayName: 'Echo pipeline runner name'

Variables can also be set or overridden in the Azure DevOps UI (including marking secrets or allowing queue-time overrides). They are ideal for controlling environments or selecting agent pools.

Best practices

Comment your YAML to explain intent for future readers.
Keep pipelines DRY — use variables and templates to reduce duplication.
Validate frequently — save and run pipelines to confirm behavior.
Use displayName to make pipeline runs easier to read in the UI.

Templates: centralize common tasks and avoid duplication

Templates let you reuse pipeline fragments across multiple pipelines. Azure DevOps supports including and extending templates and passing parameters to them. A typical pattern is to extract repeating task groups (NuGet restore, build, test) into separate YAML files and reference them with - template: 'file.yml'. Create nuget.yml for NuGet-related tasks:

# nuget.yml
steps:
- task: NuGetToolInstaller@1

- task: NuGetCommand@2
  inputs:
    command: 'restore'
    restoreSolution: '$(solution)'

Including this file in many pipeline YAMLs avoids retyping the same steps across projects.

Using templates in the main pipeline

Example main pipeline azure-pipelines.yml that reuses templates:

trigger:
- master

pool:
  vmImage: windows-latest
  name: Default

variables:
  PipelineRunnerName: 'Jeremy Morgan'
  PipelineRunnerAge: '47'
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'

steps:
- script: echo $(PipelineRunnerName)
  displayName: 'Run a one-line script'

- script: |
    echo Add other tasks to build, test, and deploy your project.
    echo See https://aka.ms/yaml
  displayName: 'Run a multi-line script'

- template: 'nuget.yml'
- template: 'build.yml'
- template: 'test.yml'

Warning: the Visual Studio build (VSBuild) and VSTest tasks require a Windows agent. Ensure your main pipeline uses a Windows VM image such as vmImage: 'windows-latest' when including those templates.

The VSBuild@1 and VSTest@2 tasks run only on Windows agents. If your pipeline includes Windows-specific templates, set vmImage: 'windows-latest' in the parent pipeline.

Example build.yml (Visual Studio build task):

# build.yml
steps:
- task: VSBuild@1
  inputs:
    solution: '$(solution)'
    msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.binariesDirectory)\\"'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

Example test.yml (VSTest task):

# test.yml
steps:
- task: VSTest@2
  inputs:
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

With templates in place, your main pipeline becomes shorter, easier to read, and centralized: a change to a template affects all pipelines that include it.

Observing templates run in the UI

When a pipeline referencing templates runs, Azure DevOps renders template steps inline in the run view. For example, after adding templates you should see your initial scripts followed by the NuGet installer/restore, then build, then tests — all listed sequentially in the run output.

A screenshot of an Azure DevOps Pipelines page for the "KodeKloudData" project showing a list of recent pipeline runs with green check marks indicating successful builds. The left sidebar shows navigation items like Overview, Boards, Repos, Pipelines, and Artifacts.

Example trimmed run log showing NuGet installer execution:

1 Starting: Checkout KodeKloudData@master to s
...
9 Syncing repository: KodeKloudData (Git)
11 git version 2.45.2.windows.1
...
Starting: NuGetToolInstaller
========================================================
Task         : NuGet tool installer
Description  : Acquires a specific version of NuGet from the internet or the tools cache and adds it to the PATH.
Version      : 1.246.1
Author       : Microsoft Corporation
Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/tool/nuget
========================================================
Found tool in cache: NuGet 6.11.0 x64
Resolved from tool cache: 6.11.0
Using version: 6.11.0
Prepending PATH environment variable with directory: C:\Users\jeremy\Downloads\agent\_work\_tool\NuGet\6.11.0\x64
Finishing: NuGetToolInstaller

You will see NuGet steps followed by Visual Studio build and VSTest steps in the overall run summary.

Closing notes

Use templates to centralize repetitive logic (NuGet restore, build, test).
Keep templates small and focused — easier to maintain and reuse.
Validate often and use displayName for meaningful pipeline run entries.
Templates and variables are practical for real-world CI/CD workflows and are commonly covered on certification exams such as AZ-400.

Introduction

Configure Activity Traceability and Flow of Work

Configure Collaboration & Communication

Work with Azure Repos and GitHub

Branching Strategies for Source Code

Configuring and Managing Repositories

Design and Implement Pipeline Automation

Design and Implement Pipelines

Implementing an Orchestration Automation Solution

Design and Implement Deployments

Design and Implement Infrastructure as Code (IaC)

Maintain Pipelines

Design and Implement Authentication and Authorization Methods

Design and Implement a Strategy for Managing Sensitive Information in Automation

Implement Security and Validate Code Bases for Compliance

Configure Monitoring for a DevOps Environment

Analyze Metrics

Design and Implement a Package Management Strategy

What is YAML for pipelines?

Creating a new pipeline in Azure DevOps

YAML structure: keys, lists, and nested dictionaries

Quick reference table: common pipeline keys

Variables in pipelines

Best practices

Templates: centralize common tasks and avoid duplication

Using templates in the main pipeline

Observing templates run in the UI

Closing notes

Watch Video

​What is YAML for pipelines?

​Creating a new pipeline in Azure DevOps

​YAML structure: keys, lists, and nested dictionaries

​Quick reference table: common pipeline keys

​Variables in pipelines

​Best practices

​Templates: centralize common tasks and avoid duplication

​Using templates in the main pipeline

​Observing templates run in the UI

​Closing notes

Watch Video

What is YAML for pipelines?

Creating a new pipeline in Azure DevOps

YAML structure: keys, lists, and nested dictionaries

Quick reference table: common pipeline keys

Variables in pipelines

Best practices

Templates: centralize common tasks and avoid duplication

Using templates in the main pipeline

Observing templates run in the UI

Closing notes