Azure Pipelines (CI/CD)

Manually building, testing, and deploying software is slow, error-prone, and inconsistent. Azure Pipelines automates this entire process. Every code change triggers an automatic sequence that builds the application, runs all tests, and deploys to the target environment — giving teams confidence that code is always in a deployable, working state.

What is CI/CD?

Continuous Integration (CI)

Continuous Integration is the practice of automatically building and testing code every time a developer pushes changes to the repository. The goal is to catch bugs early — within minutes of writing the code, not weeks later during a big release. When multiple developers work on the same codebase, CI ensures changes integrate cleanly and tests always pass.

Continuous Delivery / Deployment (CD)

Continuous Delivery extends CI by automatically deploying the tested code to a staging environment and preparing it for release. The final deployment to production may still require manual approval. Continuous Deployment takes it one step further — even the production deployment is fully automatic if all tests pass.

CI/CD Pipeline Flow

  Developer pushes code to Azure Repos
          │
          ▼
  ┌──────────────────────┐
  │   CI Pipeline        │
  │                      │
  │  1. Checkout code    │
  │  2. Install deps     │
  │  3. Build / Compile  │
  │  4. Run Unit Tests   │
  │  5. Build Docker img │
  │  6. Push to ACR      │
  └──────────┬───────────┘
             │  All steps pass ✓
             ▼
  ┌──────────────────────┐
  │   CD Pipeline        │
  │                      │
  │  Stage 1: DEV        │ ← Auto-deploy
  │  Stage 2: STAGING    │ ← Auto-deploy + Run Integration Tests
  │  Stage 3: PRODUCTION │ ← Manual approval gate → Deploy
  └──────────────────────┘

Pipeline Types in Azure Pipelines

Azure Pipelines supports two ways to define a pipeline:

• Classic (UI-based): Visual editor in the Azure DevOps portal. Configure build steps using point-and-click. Easier for beginners but harder to version control.
• YAML Pipelines (Recommended): Pipeline is defined in a azure-pipelines.yml file stored in the repository alongside the application code. Every pipeline change is version-controlled, reviewable via pull requests, and portable.

YAML Pipeline Structure

  trigger:
    branches:
      include:
        - main               # Pipeline runs when code is pushed to main branch

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

  variables:
    buildConfiguration: 'Release'
    dockerRegistry: 'myacr.azurecr.io'

  stages:

  - stage: Build
    displayName: 'Build and Test'
    jobs:
    - job: BuildJob
      steps:
      - task: NodeTool@0
        inputs:
          versionSpec: '18.x'
        displayName: 'Install Node.js'

      - script: npm install
        displayName: 'Install Dependencies'

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

      - task: Docker@2
        displayName: 'Build and Push Docker Image'
        inputs:
          command: buildAndPush
          repository: 'myapp'
          dockerfile: './Dockerfile'
          containerRegistry: 'myACRServiceConnection'
          tags: '$(Build.BuildId)'

  - stage: DeployStaging
    displayName: 'Deploy to Staging'
    dependsOn: Build
    condition: succeeded()
    jobs:
    - deployment: DeployToStaging
      environment: 'staging'
      strategy:
        runOnce:
          deploy:
            steps:
            - task: AzureWebApp@1
              inputs:
                azureSubscription: 'MyAzureSubscription'
                appName: 'myapp-staging'
                package: '$(Pipeline.Workspace)/drop/*.zip'

  - stage: DeployProduction
    displayName: 'Deploy to Production'
    dependsOn: DeployStaging
    condition: succeeded()
    jobs:
    - deployment: DeployToProd
      environment: 'production'       # Configured with manual approval gate
      strategy:
        runOnce:
          deploy:
            steps:
            - task: AzureWebApp@1
              inputs:
                azureSubscription: 'MyAzureSubscription'
                appName: 'myapp-production'
                package: '$(Pipeline.Workspace)/drop/*.zip'

Pipeline Agents

An agent is the machine that runs pipeline steps. Azure Pipelines provides two types:

Microsoft-Hosted Agents

Pre-configured virtual machines managed by Microsoft. Each pipeline run gets a fresh, clean agent. Microsoft maintains the VMs, installs tools, and discards the agent after the run. No management required.

• ubuntu-latest (Linux)
• windows-latest (Windows Server)
• macos-latest (macOS)

Self-Hosted Agents

A machine (physical, VM, or container) that the organization manages. The Azure DevOps agent software is installed, and the machine registers itself with the pipeline. Self-hosted agents are used when:

• Builds need access to internal network resources.
• Specific hardware or software not available on hosted agents is required.
• Builds take very long and the hosted agent time limits are exceeded.

Environments and Approvals

An Environment in Azure Pipelines represents a deployment target — Dev, Staging, Production, etc. Environments can be configured with:

• Approvals: Require specific people or groups to manually approve before deployment to that environment proceeds.
• Checks: Business hours checks (deploy only during working hours), Azure Monitor alerts check (block deployment if active alerts exist), and more.
• Deployment history: Full audit trail of every deployment to each environment — who triggered it, what version was deployed, and the outcome.

Service Connections

Pipelines need credentials to deploy to Azure subscriptions, push Docker images to registries, or connect to external services. Service connections store these credentials securely in Azure DevOps so pipeline YAML files never contain passwords or keys.

• Azure Resource Manager: Deploy to an Azure subscription using a service principal.
• Docker Registry: Push images to Azure Container Registry or Docker Hub.
• GitHub / Bitbucket: Check out code from external Git repositories.
• Kubernetes: Deploy to Kubernetes clusters (AKS or others).

Pipeline Triggers

Pipeline Artifacts

Pipeline artifacts are files produced by a pipeline run and stored for use by later stages or other pipelines. Common artifacts include compiled application binaries, Docker image digests, test results, and deployment packages. Artifacts pass the output of the build stage to the deploy stage without rebuilding the application.

Key Takeaways

• Azure Pipelines automates the build, test, and deployment process — reducing manual work and human error.
• CI builds and tests code automatically on every push; CD deploys the tested build to staging and production environments.
• YAML pipelines store the pipeline definition as code in the repository — versioned, reviewable, and portable.
• Microsoft-hosted agents provide clean, pre-configured VMs for each run; self-hosted agents are used for custom requirements.
• Environments with approval gates ensure critical deployments (especially production) require human sign-off before proceeding.