Azure Pipelines for .NET — Complete Guide

Setting up CI/CD manually is slow, error-prone, and hard to scale. Every time you push code, someone has to remember to build, test, and deploy it — and eventually someone forgets. Azure Pipelines solves this by automating the entire process through a single azure-pipelines.yml file that lives in your repository.

This guide walks you through everything from creating your Azure DevOps organization to deploying a .NET app across multiple environments with approval gates — all using a free Azure account.

Prerequisites

Before you start, make sure you have:

• A free Azure account → portal.azure.com
• A GitHub or Azure Repos repository containing a .NET project (.csproj or .sln)
• Basic familiarity with Git (commit, push, branch)
• .NET SDK 10 installed locally for testing your project before pushing

Step 1: Set Up Azure DevOps

1. Go to dev.azure.com and sign in with your Azure account
2. Click New organization and follow the prompts
3. Create a new project — give it a name such as my-dotnet-pipeline, set visibility to Private, and click Create

Important: New Azure DevOps accounts do not automatically receive a free Microsoft-hosted parallel job — this applies to both private and public projects. You must request it manually. This is completely free, no credit card or billing required. You can verify your current status at Organization Settings → Pipelines → Parallel jobs — if Microsoft-hosted shows 0, you need to request the grant. Fill in the form at aka.ms/azpipelines-parallelism-request. Approval typically takes 2–3 business days.

Step 2: Connect Your Repository

1. Inside your project, navigate to Pipelines → Create Pipeline
2. Select where your code lives — GitHub, Azure Repos Git, or Bitbucket Cloud
3. Choose your repository from the list
4. Authorize Azure DevOps access (an OAuth popup appears for GitHub)
5. Azure will suggest a starter template — you can dismiss it and write your own YAML instead

Step 3: Create azure-pipelines.yml

Create a file named azure-pipelines.yml in the root of your repository. This file is the single source of truth for your pipeline.

Here is the minimal working example to get started:

trigger:
  - main

pool:
  vmImage: 'ubuntu-latest'

variables:
  dotnetVersion: '10.x'

steps:
  - task: UseDotNet@2
    inputs:
      packageType: 'sdk'
      version: $(dotnetVersion)
    displayName: 'Install .NET SDK'

  - script: dotnet --version
    displayName: 'Print .NET Version'

  - script: dotnet build
    displayName: 'Build Solution'

Commit and push this file to your repository — the pipeline will trigger automatically on the next push to main.

Step 4: Key Concepts

Before writing more complex pipelines, it helps to understand the building blocks:

Step 5: Run Your Pipeline

1. Push azure-pipelines.yml to your repository
2. Go to Azure DevOps → Pipelines — your pipeline will appear in the list
3. Click Run pipeline or let it trigger automatically from your push
4. Click into the run to see live logs for each step
5. A green checkmark means success ✅ — a red X means failure ❌ (click the step to see the full error log)

Step 6: Triggers

Triggers control exactly when your pipeline runs. Here are the most common patterns:

# Run on specific branches only
trigger:
  branches:
    include:
      - main
      - develop
    exclude:
      - feature/*

# Run on Pull Requests — acts as a CI gate before merging
pr:
  branches:
    include:
      - main

# Scheduled nightly build at 2:00 AM UTC
schedules:
  - cron: "0 2 * * *"
    displayName: Nightly Build
    branches:
      include:
        - main
    always: true    # Run even when there are no new commits

# Disable automatic triggering — manual runs only
trigger: none

Step 7: Variables and Secrets

Defining Variables

variables:
  dotnetVersion: '10.x'
  buildConfiguration: 'Release'
  projectName: 'MyApp'

steps:
  - script: echo "Building $(projectName) in $(buildConfiguration) mode"
    displayName: 'Print Variables'

Storing Secrets Safely

Never hardcode passwords, tokens, or connection strings in your YAML file. Instead:

1. Go to Pipelines → Edit → Variables (top-right corner)
2. Click + Add, enter a name such as CONNECTION_STRING, and paste the value
3. Check Keep this value secret 🔒 and click Save

Reference it in your pipeline like this:

steps:
  - script: echo "Running migration..."
    displayName: 'Run DB Migration'
    env:
      CONNECTION_STRING: $(CONNECTION_STRING)

Sharing Variables Across Pipelines

variables:
  - group: dotnet-shared-vars    # Created under Library → Variable Groups
  - name: buildConfiguration
    value: 'Release'

Understanding Jobs

In Azure Pipelines, a job is a unit of work that runs on an agent. To understand why jobs exist, it helps to see the full hierarchy:

Pipeline
  └── Stage
        └── Job        ← runs on ONE agent
              └── Steps (tasks/scripts)

The main reason jobs exist is parallelism and isolation. Each job runs on its own agent — its own clean machine or container — independently from other jobs, and can run in parallel with them.

A practical example: say you want to test your .NET app on multiple platforms at the same time:

jobs:
  - job: TestOnLinux
    pool:
      vmImage: 'ubuntu-latest'
    steps:
      - script: dotnet test

  - job: TestOnWindows
    pool:
      vmImage: 'windows-latest'
    steps:
      - script: dotnet test

Both jobs run simultaneously, cutting your pipeline duration in half. You couldn't do that with steps alone, because steps run sequentially on the same agent.

Other reasons to split work into multiple jobs:

• Different environments — one job builds, another deploys to a different machine
• Isolation — if one job fails, others can still run independently
• Dependencies — use dependsOn to say "run this job only after that job succeeds"

In short: if you only had steps, everything would run sequentially on one machine. Jobs give you parallelism and flexibility.

Understanding Stages

Same idea as jobs, but at a higher level. Jobs give you parallelism — stages give you control over the flow.

Pipeline
  └── Stage: Build        ← must finish first
        └── Job
  └── Stage: Test         ← runs after Build
        └── Job
  └── Stage: Deploy       ← runs after Test, only on main
        └── Job

The key things stages give you that jobs alone can't:

• Sequential gates — you don't want to deploy if the build failed. Stages enforce that order explicitly
• Approval gates — you can pause the pipeline between stages and require a human to approve before continuing (e.g. before deploying to production)
• Environment promotion — DEV → STAGING → PROD is a natural stage flow, each with different conditions and approvals
• Visibility — in the Azure DevOps UI, stages appear as separate visual blocks with their own status, making it easy to see exactly where a pipeline is or where it failed
• Scoped conditions — you can say "only run the Deploy stage if we're on the main branch" without affecting the Build or Test stages

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

  - stage: Test
    dependsOn: Build          # Only runs if Build succeeds
    jobs:
      - job: TestJob
        steps:
          - script: dotnet test

  - stage: Deploy
    dependsOn: Test
    condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
    jobs:
      - deployment: DeployJob
        environment: 'production'   # Can require manual approval here
        strategy:
          runOnce:
            deploy:
              steps:
                - script: echo "Deploying to production..."

In short — if you only had jobs, you'd have parallelism but no clean way to model "this group of work must fully succeed before that group starts." Stages are the mechanism for that.

Full Examples

Example 1: Simple Build

A clean restore → build pipeline — a good starting point for any .NET project.

trigger:
  - main

pool:
  vmImage: 'ubuntu-latest'

variables:
  dotnetVersion: '10.x'
  buildConfiguration: 'Release'

steps:
  - task: UseDotNet@2
    displayName: 'Install .NET SDK'
    inputs:
      packageType: 'sdk'
      version: $(dotnetVersion)

  - task: DotNetCoreCLI@2
    displayName: 'Restore NuGet Packages'
    inputs:
      command: 'restore'
      projects: '**/*.csproj'

  - task: DotNetCoreCLI@2
    displayName: 'Build Solution'
    inputs:
      command: 'build'
      projects: '**/*.csproj'
      arguments: '--configuration $(buildConfiguration) --no-restore'

  - script: |
      echo "Build ID:  $(Build.BuildId)"
      echo "Branch:    $(Build.SourceBranchName)"
      echo "Config:    $(buildConfiguration)"
    displayName: 'Print Build Info'

Example 2: Web API (Build + Test + Publish)

A three-stage pipeline suited for an ASP.NET Core Web API. It builds the app, runs unit tests with code coverage, and publishes the artifact — deploying only on pushes to main.

trigger:
  - main

pr:
  - main

pool:
  vmImage: 'ubuntu-latest'

variables:
  dotnetVersion: '10.x'
  buildConfiguration: 'Release'
  artifactName: 'drop'

stages:

  - stage: Build
    displayName: '🔨 Build'
    jobs:
      - job: BuildJob
        displayName: 'Restore, Build & Publish'
        steps:
          - task: UseDotNet@2
            displayName: 'Install .NET SDK'
            inputs:
              packageType: 'sdk'
              version: $(dotnetVersion)

          - task: DotNetCoreCLI@2
            displayName: 'Restore'
            inputs:
              command: 'restore'
              projects: '**/*.csproj'

          - task: DotNetCoreCLI@2
            displayName: 'Build'
            inputs:
              command: 'build'
              projects: '**/*.csproj'
              arguments: '--configuration $(buildConfiguration) --no-restore'

          - task: DotNetCoreCLI@2
            displayName: 'Publish Web API'
            inputs:
              command: 'publish'
              publishWebProjects: true
              arguments: '--configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)'
              zipAfterPublish: true

          - publish: $(Build.ArtifactStagingDirectory)
            artifact: $(artifactName)
            displayName: 'Upload Build Artifact'

  - stage: Test
    displayName: '🧪 Test'
    dependsOn: Build
    jobs:
      - job: UnitTests
        displayName: 'Run Unit Tests'
        steps:
          - task: UseDotNet@2
            inputs:
              packageType: 'sdk'
              version: $(dotnetVersion)

          - task: DotNetCoreCLI@2
            displayName: 'Run Tests with Coverage'
            inputs:
              command: 'test'
              projects: '**/*Tests/*.csproj'
              arguments: >
                --configuration $(buildConfiguration)
                --collect:"XPlat Code Coverage"
                --logger trx
                --results-directory $(Agent.TempDirectory)

          - task: PublishTestResults@2
            displayName: 'Publish Test Results'
            inputs:
              testResultsFormat: 'VSTest'
              testResultsFiles: '**/*.trx'
              searchFolder: $(Agent.TempDirectory)
            condition: always()

          - task: PublishCodeCoverageResults@2
            displayName: 'Publish Code Coverage'
            inputs:
              summaryFileLocation: '$(Agent.TempDirectory)/**/coverage.cobertura.xml'
            condition: always()

  - stage: Deploy
    displayName: '🚀 Deploy'
    dependsOn: Test
    condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
    jobs:
      - deployment: DeployJob
        displayName: 'Deploy to Production'
        environment: 'production'
        strategy:
          runOnce:
            deploy:
              steps:
                - download: current
                  artifact: $(artifactName)
                  displayName: 'Download Artifact'

                - script: |
                    echo "Deploying build $(Build.BuildId)..."
                    ls $(Pipeline.Workspace)/$(artifactName)
                  displayName: 'Deploy Web API'

Example 3: NuGet Package

Builds a class library, packs it as a NuGet package with a version tied to the build ID, and pushes it to an Azure Artifacts feed.

trigger:
  - main

pool:
  vmImage: 'ubuntu-latest'

variables:
  dotnetVersion: '10.x'
  buildConfiguration: 'Release'
  majorMinorVersion: '1.0'
  nugetVersion: '$(majorMinorVersion).$(Build.BuildId)'

stages:
  - stage: Build
    displayName: '🔨 Build & Pack'
    jobs:
      - job: PackJob
        displayName: 'Build and Create NuGet Package'
        steps:
          - task: UseDotNet@2
            displayName: 'Install .NET SDK'
            inputs:
              packageType: 'sdk'
              version: $(dotnetVersion)

          - task: DotNetCoreCLI@2
            displayName: 'Restore'
            inputs:
              command: 'restore'
              projects: '**/*.csproj'

          - task: DotNetCoreCLI@2
            displayName: 'Build'
            inputs:
              command: 'build'
              projects: '**/*.csproj'
              arguments: '--configuration $(buildConfiguration) --no-restore'

          - task: DotNetCoreCLI@2
            displayName: 'Run Tests'
            inputs:
              command: 'test'
              projects: '**/*Tests/*.csproj'
              arguments: '--configuration $(buildConfiguration) --no-build'

          - task: DotNetCoreCLI@2
            displayName: 'Pack NuGet Package'
            inputs:
              command: 'pack'
              packagesToPack: '**/*.csproj'
              nobuild: true
              versioningScheme: 'byEnvVar'
              versionEnvVar: 'nugetVersion'

          - publish: $(Build.ArtifactStagingDirectory)
            artifact: 'nuget-packages'
            displayName: 'Upload NuGet Packages'

  - stage: Publish
    displayName: '📦 Publish to Azure Artifacts'
    dependsOn: Build
    condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
    jobs:
      - job: PublishJob
        steps:
          - download: current
            artifact: 'nuget-packages'

          - task: DotNetCoreCLI@2
            displayName: 'Push to Internal Feed'
            inputs:
              command: 'push'
              packagesToPush: '$(Pipeline.Workspace)/nuget-packages/*.nupkg'
              nuGetFeedType: 'internal'
              publishVstsFeed: 'my-feed'    # Replace with your feed name

Example 4: Docker Build and Push

Builds and tests the .NET app first, then packages it into a Docker image and pushes it to Azure Container Registry.

trigger:
  - main

pool:
  vmImage: 'ubuntu-latest'

variables:
  dotnetVersion: '10.x'
  buildConfiguration: 'Release'
  dockerRegistry: 'myregistry.azurecr.io'
  imageName: 'my-dotnet-app'
  imageTag: '$(Build.BuildId)'

stages:
  - stage: Build
    displayName: '🔨 Build & Test'
    jobs:
      - job: BuildJob
        steps:
          - task: UseDotNet@2
            inputs:
              packageType: 'sdk'
              version: $(dotnetVersion)

          - task: DotNetCoreCLI@2
            displayName: 'Restore'
            inputs:
              command: 'restore'
              projects: '**/*.csproj'

          - task: DotNetCoreCLI@2
            displayName: 'Build'
            inputs:
              command: 'build'
              projects: '**/*.csproj'
              arguments: '--configuration $(buildConfiguration) --no-restore'

          - task: DotNetCoreCLI@2
            displayName: 'Test'
            inputs:
              command: 'test'
              projects: '**/*Tests/*.csproj'
              arguments: '--configuration $(buildConfiguration) --no-build'

  - stage: Docker
    displayName: '🐳 Docker Build & Push'
    dependsOn: Build
    jobs:
      - job: DockerJob
        steps:
          - task: Docker@2
            displayName: 'Login to ACR'
            inputs:
              command: 'login'
              containerRegistry: 'my-acr-service-connection'

          - task: Docker@2
            displayName: 'Build Image'
            inputs:
              command: 'build'
              repository: '$(dockerRegistry)/$(imageName)'
              dockerfile: '**/Dockerfile'
              buildContext: '.'
              tags: |
                $(imageTag)
                latest

          - task: Docker@2
            displayName: 'Push to ACR'
            inputs:
              command: 'push'
              repository: '$(dockerRegistry)/$(imageName)'
              tags: |
                $(imageTag)
                latest

Place this Dockerfile in your project root alongside the .csproj:

# Build stage
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src
COPY ["MyApp/MyApp.csproj", "MyApp/"]
RUN dotnet restore "MyApp/MyApp.csproj"
COPY . .
WORKDIR "/src/MyApp"
RUN dotnet publish "MyApp.csproj" -c Release -o /app/publish

# Runtime stage
FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS runtime
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "MyApp.dll"]

Example 5: Multi-Environment with Approvals

A production-grade pipeline that promotes through DEV → STAGING → PRODUCTION. DEV deploys automatically, and production requires a manual approval before it runs.

trigger:
  - main

pool:
  vmImage: 'ubuntu-latest'

variables:
  dotnetVersion: '10.x'
  buildConfiguration: 'Release'
  artifactName: 'webapp'

stages:

  - stage: Build
    displayName: '🔨 Build'
    jobs:
      - job: BuildJob
        steps:
          - task: UseDotNet@2
            inputs:
              packageType: 'sdk'
              version: $(dotnetVersion)

          - task: DotNetCoreCLI@2
            displayName: 'Restore'
            inputs:
              command: 'restore'
              projects: '**/*.csproj'

          - task: DotNetCoreCLI@2
            displayName: 'Build'
            inputs:
              command: 'build'
              projects: '**/*.csproj'
              arguments: '--configuration $(buildConfiguration) --no-restore'

          - task: DotNetCoreCLI@2
            displayName: 'Test'
            inputs:
              command: 'test'
              projects: '**/*Tests/*.csproj'
              arguments: '--configuration $(buildConfiguration) --no-build'

          - task: DotNetCoreCLI@2
            displayName: 'Publish'
            inputs:
              command: 'publish'
              publishWebProjects: true
              arguments: '--configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)'
              zipAfterPublish: true

          - publish: $(Build.ArtifactStagingDirectory)
            artifact: $(artifactName)

  - stage: DeployDev
    displayName: '🟡 Deploy to DEV'
    dependsOn: Build
    jobs:
      - deployment: DevDeploy
        environment: 'dev'              # No approval — deploys automatically
        strategy:
          runOnce:
            deploy:
              steps:
                - download: current
                  artifact: $(artifactName)
                - task: AzureWebApp@1
                  displayName: 'Deploy to Dev App Service'
                  inputs:
                    azureSubscription: 'my-azure-service-connection'
                    appType: 'webApp'
                    appName: 'my-dotnet-app-dev'
                    package: '$(Pipeline.Workspace)/$(artifactName)/**/*.zip'

  - stage: DeployStaging
    displayName: '🟠 Deploy to STAGING'
    dependsOn: DeployDev
    jobs:
      - deployment: StagingDeploy
        environment: 'staging'
        strategy:
          runOnce:
            deploy:
              steps:
                - download: current
                  artifact: $(artifactName)
                - task: AzureWebApp@1
                  displayName: 'Deploy to Staging App Service'
                  inputs:
                    azureSubscription: 'my-azure-service-connection'
                    appType: 'webApp'
                    appName: 'my-dotnet-app-staging'
                    package: '$(Pipeline.Workspace)/$(artifactName)/**/*.zip'

  - stage: DeployProd
    displayName: '🟢 Deploy to PRODUCTION'
    dependsOn: DeployStaging
    jobs:
      - deployment: ProdDeploy
        environment: 'production'       # Requires manual approval before this stage runs
        strategy:
          runOnce:
            deploy:
              steps:
                - download: current
                  artifact: $(artifactName)
                - task: AzureWebApp@1
                  displayName: 'Deploy to Production App Service'
                  inputs:
                    azureSubscription: 'my-azure-service-connection'
                    appType: 'webApp'
                    appName: 'my-dotnet-app-prod'
                    package: '$(Pipeline.Workspace)/$(artifactName)/**/*.zip'

To configure the approval gate: go to Pipelines → Environments → production → Approvals and checks → Add → Approvals, then specify who must approve each production deployment.

Free Tier Limits

A typical .NET pipeline run takes 3–6 minutes, so the free 1,800 minutes per month is more than sufficient for learning and side projects.

One-time action required: Microsoft does not grant a free Microsoft-hosted parallel job automatically — this applies to both private and public projects. Check your status at Organization Settings → Pipelines → Parallel jobs. If Microsoft-hosted shows 0, fill in the free request form at aka.ms/azpipelines-parallelism-request right after creating your organization. No credit card or payment needed.

Troubleshooting

Pipeline not triggering after a push? Make sure azure-pipelines.yml is in the root of the repository and the branch name in trigger: matches your actual branch (e.g. main vs master).

"No hosted parallelism has been purchased or granted" This means the free parallel job grant has not been approved yet. Submit the form at aka.ms/azpipelines-parallelism-request and wait for approval.

dotnet restore fails with a feed authentication error Your project likely references a private NuGet feed. Store the feed credentials in a Variable Group under Library and expose them to the restore step via env:.

Tests are not discovered Check that your test project paths match the glob pattern **/*Tests/*.csproj. Adjust the pattern to match your naming convention, for example **/*.Tests.csproj.

Artifact not found in a later stage Ensure the Build stage has a publish: step and subsequent stages use a download: step with the matching artifact name.

Conclusion

Azure Pipelines gives .NET developers a powerful, free CI/CD platform that integrates directly with GitHub or Azure Repos. Starting from a minimal azure-pipelines.yml, you can progressively add stages for testing, packaging, containerization, and multi-environment deployments with approval gates — all in a single YAML file that lives alongside your code.

The five examples in this guide cover the most common real-world scenarios: a basic build, a Web API with test coverage, NuGet packaging, Docker container publishing, and a full DEV → STAGING → PROD promotion flow. Use them as starting points and adapt them to your project structure as your pipeline matures.

Property Reference

A complete reference of all azure-pipelines.yml properties with descriptions.

Root Properties

Top-level properties of the azure-pipelines.yml file:

trigger

Controls automatic pipeline runs when code is pushed to the repository:

# Example
trigger:
  branches:
    include:
      - main
      - develop
    exclude:
      - feature/*
  paths:
    include:
      - src/
  batch: true

pr

Runs the pipeline as a CI check when a Pull Request is created or updated:

# Example
pr:
  branches:
    include:
      - main
  paths:
    include:
      - src/
  autoCancel: true
  drafts: false

schedules

Automatic scheduled runs using cron syntax (UTC):

# Example — every day at 02:00 UTC
schedules:
  - cron: "0 2 * * *"
    displayName: Nightly Build
    branches:
      include:
        - main
    always: true

pool

Defines the agent the pipeline or an individual job runs on:

# Microsoft-hosted agent
pool:
  vmImage: 'ubuntu-latest'

# Self-hosted agent
pool:
  name: 'MyAgentPool'
  demands:
    - dotnet

variables

Defines variables accessible via $(name):

# Example
variables:
  - group: my-variable-group
  - name: buildConfiguration
    value: 'Release'
  - name: dotnetVersion
    value: '10.x'

stages

Top-level organizational units of the pipeline:

# Example
stages:
  - stage: Build
    displayName: '🔨 Build'
    jobs:
      - job: BuildJob
        steps:
          - script: dotnet build

  - stage: Deploy
    displayName: '🚀 Deploy'
    dependsOn: Build
    condition: succeeded()
    jobs:
      - job: DeployJob
        steps:
          - script: echo "Deploying..."

jobs

A unit of work inside a stage. Multiple jobs can run in parallel:

# Example with matrix strategy
jobs:
  - job: Test
    strategy:
      matrix:
        dotnet10:
          dotnetVersion: '10.x'
        dotnet8:
          dotnetVersion: '8.x'
    steps:
      - task: UseDotNet@2
        inputs:
          versionSpec: $(dotnetVersion)
      - script: dotnet test

steps

Properties shared by all step types (script, task, bash, etc.):

# Example
steps:
  - script: dotnet test
    displayName: 'Run Tests'
    condition: succeeded()
    continueOnError: false
    timeoutInMinutes: 10
    retryCountOnTaskFailure: 2
    env:
      MY_SECRET: $(MY_SECRET)

task

Built-in and marketplace tasks available in Azure DevOps:

# Most common .NET tasks
- task: UseDotNet@2
  inputs:
    packageType: 'sdk'
    versionSpec: '10.x'

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

script / bash / pwsh

Run shell commands directly as a step:

# Examples
- script: echo "Hello from cmd/bash"
  displayName: 'script step'

- bash: |
    echo "Always bash"
    dotnet --version
  displayName: 'bash step'

- pwsh: |
    Write-Host "PowerShell Core"
  displayName: 'pwsh step'

publish / download

Pass files between stages using pipeline artifacts:

# Publish artifact
- task: DotNetCoreCLI@2
  inputs:
    command: 'publish'
    arguments: '--output $(Build.ArtifactStagingDirectory)'

- publish: $(Build.ArtifactStagingDirectory)
  artifact: drop

# Download in a later stage
- download: current
  artifact: drop

- script: ls $(Pipeline.Workspace)/drop

deployment

A special job type for deployments with environment support and approval gates:

# Example
- deployment: DeployProd
  displayName: 'Deploy to PROD'
  environment: 'production'
  strategy:
    runOnce:
      preDeploy:
        steps:
          - script: echo "Pre-deployment check"
      deploy:
        steps:
          - download: current
            artifact: drop
          - task: AzureWebApp@1
            inputs:
              azureSubscription: 'my-connection'
              appName: 'my-app-prod'
              package: '$(Pipeline.Workspace)/drop/**/*.zip'
      postDeploy:
        steps:
          - script: echo "Deployment successful"
      on:
        failure:
          steps:
            - script: echo "Deployment failed!"

condition

Expressions for conditional execution of steps, jobs, and stages:

# Usage examples
- script: echo "Main branch only"
  condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')

- script: echo "Always, even on failure"
  condition: always()

- stage: Deploy
  condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))

dependsOn

Controls the execution order of stages and jobs:

# Examples
stages:
  - stage: A
  - stage: B
    dependsOn: A        # After A
  - stage: C
    dependsOn: []       # Parallel with A and B
  - stage: D
    dependsOn: [B, C]   # After B and C

Built-in Variables

Variables automatically provided by Azure Pipelines in every run: