Azure DevOps YAML – Stages, Jobs, Steps, Tasks, and Scripts

1. What are Stages, Jobs, Steps, Tasks, and Scripts?

In Azure DevOps YAML pipelines, Stages, Jobs, Steps, Tasks, and Scripts define how CI/CD operations are organized and executed.

Each component has a specific responsibility.

Execution hierarchy

Important: Tasks and scripts are both types of steps. They are not separate mandatory hierarchy levels.

2. What is a Stage?

A Stage represents a major phase of the CI/CD pipeline.

Common stages include:

• Build

• Test

• Deploy to SIT

• Deploy to UAT

• Deploy to Production

YAML syntax

stages:
  - stage: Build
    displayName: 'Build Application'
    jobs:
      - job: BuildJob
        steps:
          - script: dotnet build

How does it work?

1. Azure DevOps starts the Build stage.

2. It executes the jobs defined inside that stage.

3. The stage succeeds when its required jobs succeed.

4. The next dependent stage starts if its conditions are satisfied.

By default, stages run sequentially. You can use dependsOn to control dependencies and allow independent stages to run in parallel.

Example: Multiple stages

stages:

  - stage: Build
    jobs:
      - job: BuildJob
        steps:
          - script: dotnet build

  - stage: Test
    jobs:
      - job: TestJob
        steps:
          - script: dotnet test

Here, the Test stage runs after the Build stage succeeds.

3. What is a Job?

A Job is a collection of steps executed together.

For a normal agent job, Azure DevOps assigns an agent to execute its steps.

YAML syntax

jobs:
  - job: BuildJob
    displayName: 'Build Web API'

    pool:
      vmImage: 'ubuntu-latest'

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

How does it work?

1. Azure DevOps schedules the job.

2. An available agent is assigned.

3. The agent downloads the source code by default.

4. Steps execute sequentially.

5. The job succeeds or fails based on its execution results.

Can a stage contain multiple jobs?

Yes.

stages:
  - stage: Build

    jobs:
      - job: BackendJob
        steps:
          - script: dotnet build

      - job: FrontendJob
        steps:
          - script: npm install
          - script: npm run build

In this example, BackendJob and FrontendJob can run in parallel, subject to agent availability and parallel-job limits.

Important: Each agent job may execute on a different agent. Files generated by one job are not automatically available to another job. Use pipeline artifacts to transfer outputs between jobs when necessary.

4. What is a Step?

A Step is an individual operation performed inside a job.

A step can execute:

• A predefined task.

• A command-line script.

• A PowerShell script.

• A Bash script.

• A YAML template containing reusable steps.

YAML syntax

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

  - script: dotnet build
    displayName: 'Build Application'

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

How does it work?

Steps execute sequentially within the same job.

Step 1: dotnet restore
          ↓
Step 2: dotnet build
          ↓
Step 3: dotnet test
          ↓
       Job Completed

By default, if a step fails, subsequent steps are skipped unless their execution conditions allow them to run.

5. What is a Task?

A Task is a predefined operation provided by Azure DevOps or an installed extension.

Instead of manually writing commands, we can use built-in tasks.

Example: Install .NET SDK

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

Explanation

Common Azure DevOps tasks

Example: Build using a predefined task

steps:
  - task: DotNetCoreCLI@2
    displayName: 'Build Web API'
    inputs:
      command: 'build'
      projects: '**/*.csproj'
      arguments: '--configuration Release'

This task executes the .NET build operation.

6. What is a Script?

A Script allows us to execute custom commands inside a pipeline.

Scripts are useful when we want direct control over build, test, or deployment commands.

Example 1: Command-line script

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

  - script: dotnet build
    displayName: 'Build Application'

The script shortcut uses the platform's command-line shell: typically Bash on Linux/macOS and cmd.exe on Windows.

Example 2: PowerShell

steps:
  - powershell: |
      Write-Host "Starting Build"
      dotnet restore
      dotnet build
    displayName: 'PowerShell Build'

Example 3: Bash

steps:
  - bash: |
      echo "Starting Build"
      dotnet restore
      dotnet build
    displayName: 'Bash Build'

Key point: Use script, bash, pwsh, or powershell depending on the shell and operating system requirements.

7. Difference Between Task and Script

This is an important Azure DevOps interview question.

Same operation using Task and Script

- task: DotNetCoreCLI@2
  inputs:
    command: 'build'
    projects: '**/*.csproj'

- script: dotnet build

Both can perform a build, although the task example explicitly selects project files while the script relies on the current directory.

8. Complete Practical Example – ASP.NET Core Web API

The following example demonstrates stages, jobs, steps, tasks, and scripts in one YAML pipeline.

trigger:
  - main

pool:
  vmImage: 'ubuntu-latest'

variables:
  buildConfiguration: 'Release'

stages:

  # Stage 1: Build
  - stage: Build
    displayName: 'Build Stage'

    jobs:
      - job: BuildJob
        displayName: 'Build Web API'

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

          - script: dotnet restore
            displayName: 'Restore Packages'

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

  # Stage 2: Test
  - stage: Test
    displayName: 'Test Stage'
    dependsOn: Build

    jobs:
      - job: TestJob
        displayName: 'Run Unit Tests'

        steps:
          - task: UseDotNet@2
            inputs:
              packageType: 'sdk'
              version: '8.0.x'

          - script: dotnet test --configuration $(buildConfiguration)
            displayName: 'Execute Unit Tests'

  # Stage 3: Publish
  - stage: Publish
    displayName: 'Publish Stage'
    dependsOn: Test

    jobs:
      - job: PublishJob

        steps:
          - task: UseDotNet@2
            inputs:
              packageType: 'sdk'
              version: '8.0.x'

          - script: dotnet publish --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)/publish
            displayName: 'Publish Application'

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

This assumes a repository with a suitable .NET solution or project in its working directory. Each job restores or builds what it needs because Microsoft-hosted jobs use fresh agents.

Execution flow

Developer Pushes Code to main
             |
             v
       Stage: Build
             |
          BuildJob
             |
       Install .NET SDK
             |
       Restore Packages
             |
       Build Application
             |
             v
        Stage: Test
             |
           TestJob
             |
        Run Unit Tests
             |
             v
       Stage: Publish
             |
         PublishJob
             |
      Publish Application
             |
      Upload Build Artifact
             |
             v
      Pipeline Completed

This example creates a CI pipeline. A separate deployment stage could download the artifact and deploy it to SIT, UAT, or Production.

9. Important Execution Rules

Example: Run a job only after another job

jobs:
  - job: BuildJob
    steps:
      - script: dotnet build

  - job: TestJob
    dependsOn: BuildJob
    steps:
      - script: dotnet test

Here, TestJob starts only after BuildJob succeeds under the default condition.

10. Interview Questions and Answers

Q1. What is the execution hierarchy of an Azure YAML pipeline?

A pipeline contains stages, stages contain jobs, and jobs contain steps. Each step can execute a task or script.

Q2. Can a stage contain multiple jobs?

Yes. A stage can contain multiple jobs, which can execute in parallel unless dependencies restrict them.

Q3. Can a job contain multiple stages?

No. Stages contain jobs, not the other way around.

Q4. What is the difference between a job and a step?

A job is a collection of steps executed on an agent or server. A step is an individual operation inside that job.

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

A task is a predefined operation such as UseDotNet@2, while a script executes custom commands such as dotnet build.

Q6. Can multiple jobs execute on the same agent?

Yes, particularly with self-hosted agents, but separate jobs are not guaranteed to use the same agent. An agent normally executes only one job at a time.

Q7. What happens if a step fails?

By default, the job fails, and subsequent steps are skipped unless configured otherwise using conditions or continueOnError.

Q8. What is the purpose of dependsOn?

dependsOn defines dependencies between jobs or stages and controls their execution order.

11. Key Points to Remember

• Stage: Major CI/CD phase.

• Job: Collection of steps executed on an agent or server.

• Step: Individual execution unit inside a job.

• Task: Predefined Azure DevOps operation.

• Script: Custom shell commands.

• Stages: Sequential by default.

• Jobs: Parallel by default when independent.

• Steps: Sequential within a job.

• dependsOn: Controls dependencies.

• condition: Controls whether a stage, job, or step runs.

Interview-ready answer:

In Azure DevOps YAML pipelines, stages, jobs, and steps organize the CI/CD execution hierarchy. A stage represents a major phase such as Build, Test, or Deploy. Each stage contains one or more jobs, and each job contains steps. Steps execute predefined tasks or custom scripts. By default, stages execute sequentially, independent jobs can run in parallel, and steps within a job execute sequentially. We can control execution using dependsOn and condition.