Azure DevOps YAML Pipeline – Structure and Configuration

1. What is an Azure DevOps YAML Pipeline?

An Azure DevOps YAML Pipeline is a CI/CD pipeline defined using a YAML (YAML Ain't Markup Language) configuration file.

Instead of manually configuring build and deployment steps through the Azure DevOps interface, we define the entire pipeline using YAML code.

A YAML pipeline can automate:

• Build: Compile application source code.

• Test: Execute automated unit tests.

• Publish: Generate build artifacts.

• Deploy: Deploy applications to environments such as Development, SIT, UAT, and Production.

Why do we need YAML pipelines?

Suppose you are developing an ASP.NET Core Web API application.

Whenever a developer pushes code to the main branch, you want Azure DevOps to automatically:

1. Download the latest source code.

2. Restore NuGet packages.

3. Build the .NET application.

4. Execute unit tests.

5. Publish the application.

6. Store the build output as an artifact.

7. Optionally deploy the application to Azure.

Instead of performing these operations manually, we configure a YAML pipeline to automate them.

Main advantage: The pipeline configuration is stored alongside the application source code in Git, allowing version control, code review, and reuse.

2. What is azure-pipelines.yml?

azure-pipelines.yml is the conventional YAML configuration file used to define an Azure DevOps pipeline.

It contains instructions describing when the pipeline should run, where it should execute, and what operations it should perform.

Example project structure

MyWebAPI/
│
├── Controllers/
├── Services/
├── Models/
├── Program.cs
├── appsettings.json
├── MyWebAPI.csproj
│
└── azure-pipelines.yml

The YAML file is usually stored in the root directory of the Git repository, although another path or filename can be configured.

How does Azure DevOps use this file?

Important: Creating a YAML file alone does not register a pipeline in Azure DevOps. You must create a pipeline in Azure DevOps and point it to the YAML file.

3. Basic Structure of an Azure YAML Pipeline

A typical YAML pipeline contains the following components:

Basic YAML example

trigger:
  - main

pool:
  vmImage: 'ubuntu-latest'

variables:
  buildConfiguration: 'Release'

stages:
  - stage: Build
    displayName: 'Build Application'

    jobs:
      - job: BuildJob
        displayName: 'Build .NET Application'

        steps:
          - script: dotnet restore
            displayName: 'Restore Packages'

          - script: dotnet build --configuration Release
            displayName: 'Build Project'

          - script: dotnet test --configuration Release
            displayName: 'Run Unit Tests'

Explanation

1. trigger

trigger:
  - main

Automatically triggers the pipeline when code is pushed to the main branch.

2. pool

pool:
  vmImage: 'ubuntu-latest'

Specifies that the pipeline runs on a Microsoft-hosted Ubuntu agent.

Other examples:

vmImage: 'windows-latest'

vmImage: 'ubuntu-24.04'

3. variables

variables:
  buildConfiguration: 'Release'

Defines a reusable variable.

Access the variable using:

$(buildConfiguration)

For example:

- script: dotnet build --configuration $(buildConfiguration)

4. stages

stages:
  - stage: Build

Defines a major phase in the pipeline.

Examples: Build, Test, DeploySIT, DeployUAT, DeployProduction.

5. jobs

jobs:
  - job: BuildJob

Defines a group of steps executed on an agent.

6. steps

steps:
  - script: dotnet restore
  - script: dotnet build

Defines the actual operations to execute.

4. Stages, Jobs, Steps, and Tasks – Execution Hierarchy

The most important hierarchy to remember:

Execution hierarchy:

Pipeline → Stages → Jobs → Steps → Tasks/Scripts

A step can be a predefined task or a script. Tasks are not a separate mandatory hierarchy level below steps.

By default, stages execute sequentially, jobs within a stage can execute in parallel, and steps within a job execute sequentially.

5. Real-Time Example: ASP.NET Core Web API CI Pipeline

Consider an ASP.NET Core Web API application developed using .NET 8.

We want to automate:

• Restore NuGet packages.

• Build the application.

• Run unit tests.

• Publish the application.

• Upload the published files as a pipeline artifact.

Complete azure-pipelines.yml

trigger:
  branches:
    include:
      - main
      - develop

pool:
  vmImage: 'ubuntu-latest'

variables:
  buildConfiguration: 'Release'

stages:

  - stage: Build
    displayName: 'Build and Test'

    jobs:
      - job: BuildJob
        displayName: 'Build ASP.NET Core Web API'

        steps:

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

          # Restore NuGet packages
          - script: dotnet restore
            displayName: 'Restore NuGet Packages'

          # Build application
          - script: dotnet build --configuration $(buildConfiguration) --no-restore
            displayName: 'Build Application'

          # Run unit tests
          - script: dotnet test --configuration $(buildConfiguration) --no-build
            displayName: 'Run Unit Tests'

          # Publish application
          - script: dotnet publish MyWebAPI/MyWebAPI.csproj --configuration $(buildConfiguration) --no-restore --output $(Build.ArtifactStagingDirectory)/publish
            displayName: 'Publish Web API'

          # Publish pipeline artifact
          - task: PublishPipelineArtifact@1
            displayName: 'Publish Build Artifact'
            inputs:
              targetPath: '$(Build.ArtifactStagingDirectory)/publish'
              artifact: 'WebAPI'
              publishLocation: 'pipeline'

Assumes the repository contains MyWebAPI/MyWebAPI.csproj and compatible test projects. Adjust the project path to match your solution.

Important tasks explained

What happens after execution?

Azure DevOps produces a pipeline artifact named WebAPI, which can be downloaded or consumed by a deployment stage.

6. YAML Pipeline vs Classic Pipeline

Azure DevOps supports both YAML pipelines and Classic pipelines.

Interview point: YAML pipelines follow the Pipeline as Code approach, making CI/CD configurations version-controlled, reusable, and easier to maintain across environments.

7. How to Create a YAML Pipeline in Azure DevOps

1. Open your Azure DevOps organization and project.

2. Navigate to Pipelines → New Pipeline.

3. Select your source repository, such as Azure Repos Git or GitHub.

4. Select an existing YAML file or configure a starter pipeline.

5. Save the azure-pipelines.yml file in the repository.

6. Select Run to execute the pipeline.

7. Monitor stages, jobs, steps, logs, and artifacts.

For automatic execution, configure the required CI triggers. For Azure Repos pull-request validation, configure a Build validation branch policy on the target branch.

8. Advantages and Disadvantages

9. Important Interview Questions and Answers

Q1. What is a YAML pipeline in Azure DevOps?

A YAML pipeline is a CI/CD pipeline defined as code in a YAML file. It automates building, testing, publishing, and deploying applications.

Q2. Is azure-pipelines.yml a mandatory filename?

No. It is the default conventional filename. We can use another filename or location and configure Azure DevOps to reference it.

Q3. What is the difference between a stage and a job?

A stage represents a major phase, such as Build or Deploy. A job is a collection of steps executed on an agent or, for server jobs, by Azure DevOps.

Q4. What is the difference between a task and a script?

A task is a predefined pipeline operation, such as UseDotNet@2. A script executes commands such as dotnet build or npm install.

Q5. Can one YAML pipeline deploy to multiple environments?

Yes. A multi-stage YAML pipeline can deploy applications to Development, SIT, UAT, and Production, using approvals and environment-specific configurations.

Q6. Can YAML pipelines be reused across projects?

Yes. YAML templates allow common stages, jobs, steps, and configurations to be shared across pipelines.

Q7. Where should passwords and connection strings be stored?

Sensitive values should be stored securely using Azure Key Vault or secret variables/variable groups, rather than hardcoded in the YAML file.

Q8. What happens when a YAML pipeline fails?

Azure DevOps marks the affected step, job, or stage as failed and provides execution logs to identify the issue. Later operations may be skipped depending on their conditions.

10. Key Points to Remember

• YAML Pipeline: Defines CI/CD automation using code.

• azure-pipelines.yml: Stores the pipeline configuration.

• trigger: Determines when the pipeline runs.

• pool: Specifies the execution agent.

• variables: Stores reusable values.

• stages: Represents major CI/CD phases.

• jobs: Groups operations executed by an agent or server.

• steps: Individual tasks or scripts.

• Pipeline Artifact: Stores build outputs for download or deployment.

• YAML Templates: Allow pipeline configuration reuse.

Interview-ready answer:

An Azure DevOps YAML pipeline is a Pipeline as Code implementation used to automate CI/CD operations. The pipeline is usually defined in an azure-pipelines.yml file stored in a Git repository. It contains triggers, agent pools, variables, stages, jobs, and steps. When the pipeline runs, Azure DevOps executes the configured operations to build, test, publish, and deploy the application. This approach supports version control, reusability, and consistent deployment across environments.