Azure Pipelines#

Azure Pipelines is the CI/CD layer of Azure DevOps. Hosted or self-hosted runners; YAML pipelines or the older Classic UI pipelines; deep integration with Azure resources, Azure Repos, and GitHub. The operator picks it on Microsoft-shaped estates and .NET-heavy stacks where it is the path of least resistance.

Architecture#

  • Organization (Azure DevOps), the top-level scope.

  • Project, the container for repos, pipelines, boards, artifacts.

  • Pipeline, a YAML or Classic pipeline definition.

  • Run, an execution of a pipeline.

  • Stage, a logical grouping in a YAML pipeline; can run in parallel; can have approvals between them.

  • Job, runs on a single agent.

  • Agent, the worker. Microsoft-hosted (ubuntu-latest, windows-latest, macos-latest) or self-hosted (Windows, Linux, macOS, behind firewall).

Pipeline shape#

# azure-pipelines.yml
trigger:
  branches:
    include: [main]

pr:
  branches:
    include: ['*']

stages:
  - stage: Test
    jobs:
      - job: NodeTest
        pool: { vmImage: 'ubuntu-latest' }
        steps:
          - task: NodeTool@0
            inputs: { versionSpec: '22.x' }
          - script: corepack enable && pnpm install --frozen-lockfile && pnpm test
            displayName: 'pnpm test'
          - task: PublishTestResults@2
            condition: succeededOrFailed()
            inputs: { testResultsFiles: '**/junit.xml' }

  - stage: BuildPush
    dependsOn: Test
    condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
    jobs:
      - job: Docker
        pool: { vmImage: 'ubuntu-latest' }
        steps:
          - task: Docker@2
            inputs:
              command: buildAndPush
              repository: 'myorg/app'
              dockerfile: 'Dockerfile'
              containerRegistry: 'acr-connection'
              tags: |
                $(Build.SourceVersion)

Triggers#

  • CI triggers: push, branch filter, path filter, batch.

  • PR triggers: per-target-branch.

  • Scheduled triggers with cron.

  • Pipeline resource triggers (resources.pipelines) fire one pipeline off another’s completion.

Service connections#

The operator-facing primitive for auth into Azure, AWS, GCP, Docker registries, Kubernetes clusters, and arbitrary REST APIs. Configured once at the project level; referenced by name in pipelines. Recent service connections support OIDC, no client secret stored.

Variables and secrets#

  • Pipeline variables, in YAML or in the UI; can be marked secret.

  • Variable groups, reusable sets shared across pipelines; linked to Azure Key Vault for managed secrets.

  • Secure files, signing keys / certificates downloaded into the agent workspace at runtime.

Agents#

Type

Detail

Microsoft-hosted

Pre-built images for Linux, Windows, macOS. Free minutes per month; paid above.

Self-hosted

Operator-owned VMs / hosts running the agent service. Required for behind-firewall or specialized hardware.

Scale-set agents

Auto-scaling pool of Azure VMs. Ephemeral, pay-per-use.

Environments and approvals#

Environments (stage.environment) are first-class targets with deployment history, approvers, and gate checks (Azure Monitor alert, REST call, work item, business hours). The operator wires sensitive deploys through environment approvals rather than ad-hoc UI buttons.

When to pick Azure Pipelines#

  • Code on Azure Repos or GitHub Enterprise tied into Azure DevOps.

  • .NET / Windows / SQL Server workloads where the platform’s built-in tasks save effort.

  • Compliance posture requires a Microsoft-hosted control plane (Azure DevOps offers strong tenancy isolation).

When to pick something else#

  • Code on GitHub and the team has no Azure dependency; GitHub Actions is the closer integration.

  • Multi-cloud where the pipeline shouldn’t favor Azure.

  • Teams sliding away from Azure DevOps toward GitHub Actions (Microsoft has been steering the world in that direction).

References#