Azure DevOps CI/CD: A Practical Guide to Pipelines That Work

Why CI/CD Matters

Continuous Integration and Continuous Deployment (CI/CD) is the practice of automating the build, test, and deployment of your software. Without CI/CD, releases are manual, error-prone, and infrequent. With it, you can deploy confidently multiple times per day.

Azure DevOps provides a mature CI/CD platform that integrates with virtually any technology stack. This guide covers the practical patterns that make pipelines reliable in production.

Pipeline Fundamentals

YAML vs Classic Pipelines

Azure DevOps supports two pipeline formats. Choose YAML:

• YAML pipelines are code — they live in your repository, are version controlled, and go through pull request reviews like any other code
• Classic pipelines use a visual editor — easier to start with but impossible to version control or review in pull requests
• Microsoft is investing in YAML pipelines and many new features are YAML-only

Pipeline Structure

A well-organized YAML pipeline has clear stages:

stages:
  - stage: Build
    jobs:
      - job: BuildApp
        steps:
          - task: DotNetCoreCLI@2
            inputs:
              command: 'build'
  - stage: Test
    dependsOn: Build
    jobs:
      - job: RunTests
        steps:
          - task: DotNetCoreCLI@2
            inputs:
              command: 'test'
  - stage: DeployDev
    dependsOn: Test
    jobs:
      - deployment: DeployToDev
        environment: 'Development'
  - stage: DeployProd
    dependsOn: DeployDev
    jobs:
      - deployment: DeployToProd
        environment: 'Production'

Each stage has a clear purpose and explicit dependencies. The pipeline reads like a deployment plan.

Continuous Integration Best Practices

Trigger on Every Pull Request

Configure your pipeline to run on every pull request to the main branch:

• Build the application to catch compilation errors before merge
• Run unit tests to catch regressions
• Run linting and code analysis to enforce code quality standards
• Fail fast — put the fastest checks first so developers get feedback quickly

Keep Builds Fast

Slow builds slow down the entire team:

• Cache dependencies — use the Cache task to avoid downloading NuGet packages, npm modules, or Docker layers on every run
• Parallelize tests — split test suites across multiple agents
• Use incremental builds when possible — only rebuild what changed
• Target under 10 minutes for CI builds — anything longer and developers will stop waiting for results

Artifact Management

• Publish build artifacts at the end of every successful CI build
• The same artifact should be deployed to every environment — never rebuild for production
• Tag artifacts with the build number, commit hash, and branch name for traceability
• Use Azure Artifacts for package management (NuGet, npm, Maven, Python)

Continuous Deployment Best Practices

Use Environments

Azure DevOps Environments provide deployment history, approvals, and resource tracking:

• Create environments for Development, Staging, and Production
• Configure approval gates on Production — require one or two reviewers before deployment proceeds
• Use deployment strategies — rolling, canary, or blue-green depending on your application architecture

Variable Management

Never hardcode environment-specific values in your pipeline:

• Variable groups — define variables once and link them to multiple pipelines
• Azure Key Vault integration — pull secrets directly from Key Vault at runtime instead of storing them in pipeline variables
• Template expressions — use conditional logic to set variables based on the target environment
• Never store secrets in YAML files — even in a private repository, secrets in code are a security risk

Deployment Slots and Zero-Downtime

For Azure App Service deployments:

• Deploy to a staging slot first
• Run smoke tests against the staging slot to verify the deployment
• Swap slots to route production traffic to the new version
• If something goes wrong, swap back in seconds

For Kubernetes deployments:

• Use rolling updates to replace pods gradually
• Configure readiness probes so traffic only routes to healthy pods
• Keep the previous ReplicaSet available for quick rollback

Testing in the Pipeline

Test Pyramid

Structure your automated tests for speed and coverage:

• Unit tests (run in CI) — fast, isolated, test individual functions and classes
• Integration tests (run in CI or early CD) — test component interactions, database queries, API calls
• End-to-end tests (run in staging) — test full user workflows through the UI or API
• Performance tests (run periodically) — load tests to catch performance regressions

Quality Gates

Define minimum thresholds that must pass before deployment proceeds:

• Code coverage above 80%
• Zero critical or high-severity security vulnerabilities
• All unit and integration tests passing
• No linting errors

Monitoring and Observability

A pipeline is not done when the code is deployed. You need to know if the deployment is healthy:

• Configure Application Insights or equivalent monitoring before your first production deployment
• Set up alerts for error rate spikes, response time increases, and availability drops
• Include a deployment annotation in your monitoring tool so you can correlate issues with specific deployments
• Automate rollback when health checks fail within a defined window after deployment

Pipeline Security

• Use service connections with the minimum required permissions
• Require pull request reviews before merging pipeline YAML changes
• Enable branch protection on your main branch — no direct pushes
• Scan dependencies for vulnerabilities using tools like WhiteSource Bolt or GitHub Advanced Security
• Rotate secrets stored in Key Vault on a regular schedule

Start Building Better Pipelines

Al Rafay Consulting helps development teams design and implement CI/CD pipelines that are fast, reliable, and secure. Whether you are starting from scratch or modernizing existing build processes, we bring the DevOps expertise to accelerate your delivery.

Talk to our DevOps team