Azure DevOps: YAML Templates and Reusable Pipelines

1. What are YAML Templates in Azure DevOps?

A YAML template is a reusable YAML file that contains common pipeline configurations, such as build steps, testing, publishing, and deployment.

Instead of writing the same pipeline code for multiple applications, we create a common template and reuse it across different pipelines.

Simple example

Suppose we have three ASP.NET Core applications:

Application 1: Customer API
Application 2: Payment API
Application 3: Pension API

All three applications require similar CI/CD operations:

Customer API
    |
    +---- Restore NuGet Packages
    +---- Build
    +---- Run Tests
    +---- Publish

Payment API
    |
    +---- Restore NuGet Packages
    +---- Build
    +---- Run Tests
    +---- Publish

Pension API
    |
    +---- Restore NuGet Packages
    +---- Build
    +---- Run Tests
    +---- Publish

Without templates, we repeat the same YAML configuration in all three applications.

With YAML templates, we create the build logic once and reuse it for all applications.

2. Why Do We Need YAML Templates?

The main purpose is to follow the DRY (Don't Repeat Yourself) principle.

Without YAML templates

Customer API  ---> 100 lines of YAML
Payment API   ---> 100 lines of YAML
Pension API   ---> 100 lines of YAML

Total: 300 lines

Problem:
Same build logic is repeated.

If the .NET SDK version changes, we may need to update all three pipelines.

With YAML templates

             Common Build Template
                       |
          +------------+------------+
          |            |            |
          v            v            v
     Customer API  Payment API  Pension API

Now the shared build logic is maintained in one place.

Benefits:

Reduces duplicate YAML code.
Simplifies pipeline maintenance.
Standardizes build and deployment processes.
Supports multiple applications.
Makes CI/CD pipelines easier to manage.

3. Types of YAML Templates

Azure DevOps mainly supports two template approaches.

Template type	Purpose
Include templates	Reuse stages, jobs, steps, or variables
Extend templates	Define a common pipeline structure that other pipelines extend

Common reusable template structures include:

Step templates: Reuse build, test, or publish steps.
Job templates: Reuse complete jobs.
Stage templates: Reuse complete stages.
Variable templates: Reuse configuration variables.

4. How Do You Create a Reusable YAML Template?

Let's create a reusable build template for multiple ASP.NET Core Web API applications.

Step 1: Create the folder structure

Repository
│
├── templates
│   └── dotnet-build.yml
│
├── CustomerAPI
│   └── azure-pipelines.yml
│
├── PaymentAPI
│   └── azure-pipelines.yml
│
└── PensionAPI
    └── azure-pipelines.yml

Here:

dotnet-build.yml contains the common build logic.
Each application has its own pipeline YAML file.
Applications pass their project path and build configuration to the shared template.

Step 2: Create a common build template

File: templates/dotnet-build.yml

parameters:
- name: projectPath
  type: string

- name: buildConfiguration
  type: string
  default: 'Release'

steps:

# Install .NET SDK
- task: UseDotNet@2
  displayName: 'Install .NET SDK'
  inputs:
    packageType: 'sdk'
    version: '8.0.x'

# Restore Packages
- task: DotNetCoreCLI@2
  displayName: 'Restore Packages'
  inputs:
    command: 'restore'
    projects: '${{ parameters.projectPath }}'

# Build Application
- task: DotNetCoreCLI@2
  displayName: 'Build Application'
  inputs:
    command: 'build'
    projects: '${{ parameters.projectPath }}'
    arguments: >
      --configuration ${{ parameters.buildConfiguration }}
      --no-restore

# Publish Application
- task: DotNetCoreCLI@2
  displayName: 'Publish Application'
  inputs:
    command: 'publish'
    publishWebProjects: false
    projects: '${{ parameters.projectPath }}'
    arguments: >
      --configuration ${{ parameters.buildConfiguration }}
      --output $(Build.ArtifactStagingDirectory)/publish
    zipAfterPublish: true

Explanation:

parameters: accepts application-specific values.
projectPath identifies the application to build.
buildConfiguration determines Debug or Release mode.
The template restores, builds, and publishes the application.

The same template works for all three applications.

Step 3: Create the Customer API pipeline

File: CustomerAPI/azure-pipelines.yml

trigger:
  branches:
    include:
    - main
  paths:
    include:
    - CustomerAPI/**
    - templates/**

pool:
  vmImage: 'ubuntu-latest'

steps:
- template: ../templates/dotnet-build.yml
  parameters:
    projectPath: 'CustomerAPI/CustomerAPI.csproj'
    buildConfiguration: 'Release'

Step 4: Create the Payment API pipeline

File: PaymentAPI/azure-pipelines.yml

trigger:
  branches:
    include:
    - main
  paths:
    include:
    - PaymentAPI/**
    - templates/**

pool:
  vmImage: 'ubuntu-latest'

steps:
- template: ../templates/dotnet-build.yml
  parameters:
    projectPath: 'PaymentAPI/PaymentAPI.csproj'
    buildConfiguration: 'Release'

Step 5: Create the Pension API pipeline

File: PensionAPI/azure-pipelines.yml

trigger:
  branches:
    include:
    - main
  paths:
    include:
    - PensionAPI/**
    - templates/**

pool:
  vmImage: 'ubuntu-latest'

steps:
- template: ../templates/dotnet-build.yml
  parameters:
    projectPath: 'PensionAPI/PensionAPI.csproj'
    buildConfiguration: 'Release'

All three pipelines reuse the same build template.

Note: These examples assume all files are stored in one repository. Each Azure Pipeline must be configured to use its corresponding application YAML file. The template publishes output to the staging directory; publishing a downloadable Azure Pipelines artifact requires an additional artifact task.

5. How Do Reusable Pipelines Work?

Developer Pushes Code
         |
         v
Azure DevOps Detects Changes
         |
         v
Trigger Matching Application Pipeline
         |
         v
Read azure-pipelines.yml
         |
         v
Load Common YAML Template
         |
         v
Pass Application Parameters
         |
         |-- projectPath
         |-- buildConfiguration
         |
         v
Expand Template
         |
         v
Restore NuGet Packages
         |
         v
Build Application
         |
         v
Publish Application
         |
         v
Pipeline Completed

For example, when code is pushed to the CustomerAPI folder, its pipeline uses the shared template with the Customer API project path.

The Payment and Pension pipelines do not run for that change unless their configured trigger paths also match.

6. Reusable Stage Templates

In real-world projects, we can reuse entire stages instead of individual steps.

For example, we may want a reusable deployment stage.

File: templates/deploy-stage.yml

parameters:
- name: environment
  type: string

stages:
- stage: Deploy_${{ parameters.environment }}
  displayName: 'Deploy to ${{ parameters.environment }}'

  jobs:
  - deployment: DeployApplication
    environment: ${{ parameters.environment }}

    strategy:
      runOnce:
        deploy:
          steps:
          - script: |
              echo "Deploying to ${{ parameters.environment }}"

This is a simplified deployment template that demonstrates stage reuse. An actual deployment requires application artifact download and deployment tasks.

Calling the stage template

stages:
- template: templates/deploy-stage.yml
  parameters:
    environment: DEV

- template: templates/deploy-stage.yml
  parameters:
    environment: UAT

- template: templates/deploy-stage.yml
  parameters:
    environment: PROD

The template generates three deployment stages.

Azure Pipeline
     |
     v
Deploy_DEV
     |
     v
Deploy_UAT
     |
     v
Deploy_PROD

By default, these stages run sequentially, subject to successful dependencies and any configured approvals or checks.

7. Reusing Templates Across Multiple Repositories

In enterprise projects, applications may be stored in separate repositories.

For example:

Azure Repos
    |
    +---- CustomerAPI-Repo
    |
    +---- PaymentAPI-Repo
    |
    +---- PensionAPI-Repo
    |
    +---- DevOps-Templates-Repo
                 |
                 +---- dotnet-build.yml
                 +---- deploy-stage.yml

Azure DevOps supports referencing templates from another repository using resources.repositories.

Example

resources:
  repositories:
  - repository: sharedTemplates
    type: git
    name: MyProject/DevOps-Templates
    ref: refs/heads/main

pool:
  vmImage: 'ubuntu-latest'

steps:
- template: dotnet-build.yml@sharedTemplates
  parameters:
    projectPath: 'CustomerAPI/CustomerAPI.csproj'
    buildConfiguration: 'Release'

Explanation:

resources.repositories declares an external repository resource.
repository: sharedTemplates defines an alias.
type: git specifies Azure Repos Git.
name: identifies the project and repository.
@sharedTemplates loads the template from that repository.

For cross-project repositories, appropriate permissions must be granted. Production pipelines should preferably reference a reviewed template tag or commit rather than an unrestricted moving branch.

8. YAML Templates vs Variables vs Parameters

Feature	YAML Templates	Variables	Parameters
Purpose	Reuse pipeline logic	Store configuration	Provide input values
Main usage	Common build/deploy logic	Paths, versions, secrets	Environment, project selection
Reusable	Yes	Yes	Yes
Supports secrets	Through referenced variables	Yes	No
Example	`dotnet-build.yml`	`$(buildConfig)`	`${{ parameters.env }}`

These three features work together to create flexible and reusable CI/CD pipelines.

9. Advantages and Disadvantages

Advantages

Code reusability: Common pipeline logic is written once.
Easy maintenance: Update shared build logic instead of editing every application pipeline.
Standardization: Multiple applications follow consistent CI/CD practices.
Scalability: New applications can reuse existing templates.
Flexibility: Parameters allow each application to customize the shared template.

Disadvantages

Debugging complexity: Errors may originate in the calling pipeline or the shared template.
Template dependencies: Changes to shared templates can affect multiple applications.
Learning curve: Developers must understand template references, parameters, and YAML expansion.

10. Important Interview Questions and Answers

Q1. What is a YAML template in Azure DevOps?

A YAML template is a reusable YAML file containing common pipeline configurations, such as build steps, jobs, stages, or variables.

Q2. Why do we use YAML templates?

To avoid duplicate pipeline code, improve maintainability, and standardize CI/CD processes across multiple applications.

Q3. What is the difference between step, job, and stage templates?

Step templates reuse individual tasks or scripts. Job templates reuse complete jobs. Stage templates reuse entire stages.

Q4. How do you pass values to a YAML template?

Using template parameters.

- template: templates/dotnet-build.yml
  parameters:
    projectPath: 'CustomerAPI/CustomerAPI.csproj'

Q5. Can multiple applications use the same YAML template?

Yes. Multiple applications can reference the same template and pass their own project paths, build configurations, or other parameters.

Q6. Can templates be stored in a different repository?

Yes. We can reference shared templates from another Azure Repos or supported Git repository using repository resources.

Q7. What is the difference between extends and template?

template: includes reusable YAML content such as stages, jobs, or steps.
extends: allows a pipeline to inherit its overall structure from a base template.

Q8. What happens when a shared template changes?

Pipelines referencing that version of the template use the updated logic on subsequent runs. This can affect multiple applications, so template changes should be reviewed and tested.

11. Key Points for Interview

YAML templates provide reusable CI/CD pipeline configurations.
Templates reduce duplicate code and improve maintainability.
Step, job, stage, and variable templates support different reuse scenarios.
Parameters customize templates for individual applications.
template: includes reusable YAML.
extends: defines a pipeline using a base template.
Shared templates can be stored in separate repositories.
Template versioning and access controls are important for enterprise CI/CD.

Interview-ready answer

"Azure DevOps YAML templates allow us to create reusable pipeline configurations for multiple applications. Instead of duplicating build, test, and deployment steps in every application, we create common YAML templates and reference them from individual pipelines. Each application passes its own parameters, such as project path, build configuration, and deployment environment. Templates can be stored in the same repository or a centralized repository. This approach reduces duplication, improves maintainability, and standardizes CI/CD processes across projects."

Official documentation: Azure Pipelines YAML Templates