Microsoft Azure — Azure DevOps (Boards, Repos, Pipelines)

Azure is Microsoft's cloud computing platform offering over 200 services. This article covers azure devops (boards, repos, pipelines) with production-ready configurations, best practices, and hands-on examples.

Azure DevOps Overview: The Unified Toolchain

Azure DevOps is Microsoft's integrated platform for the entire software delivery lifecycle. It replaces the legacy Visual Studio Team Services (VSTS) and bundles five core services: Azure Boards for work tracking, Azure Repos for Git hosting, Azure Pipelines for CI/CD, Azure Test Plans for manual/exploratory testing, and Azure Artifacts for package management. For production teams, the key advantage is tight integration—work items link to commits, builds, and releases, providing end-to-end traceability. However, this integration comes with a cost: misconfiguration in one area can cascade. For example, a poorly structured pipeline can flood Boards with duplicate work items, or a misconfigured branch policy can block deployments. This article focuses on the three pillars most critical to DevOps: Boards, Repos, and Pipelines. We'll cover practical patterns for organizing work, managing code, and automating delivery at scale.

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

steps:
- script: echo 'Hello, Azure DevOps!'
  displayName: 'Run a one-line script'

Azure Boards: Structuring Work for Predictable Delivery

Azure Boards provides work item tracking with backlogs, boards, and sprints. The default process templates (Basic, Agile, Scrum, CMMI) define work item types (Epic, Feature, User Story, Bug, Task). For production teams, the Scrum template is most common. The critical practice is to keep work items small and well-defined. A user story should be completable within a sprint (1-2 weeks). Use acceptance criteria to define 'done'. Avoid creating tasks for every minor step—instead, use checklists within the story. Boards supports custom fields, states, and rules, but over-customization leads to maintenance debt. Stick to the built-in workflow: New -> Active -> Resolved -> Closed. Use area paths to map to teams and iteration paths to map to sprints. For traceability, link work items to commits and pull requests. This enables 'automated status updates'—when a PR merges, the linked work item can auto-transition to 'Resolved'.

# Query work items via Azure DevOps REST API
$pat = "$(System.AccessToken)"
$org = "your-org"
$project = "your-project"
$uri = "https://dev.azure.com/$org/$project/_apis/wit/wiql?api-version=6.0"
$body = @{
  query = "SELECT [System.Id], [System.Title], [System.State] FROM WorkItems WHERE [System.WorkItemType] = 'User Story' AND [System.State] <> 'Closed'"
} | ConvertTo-Json
$headers = @{Authorization = "Basic $([Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(":$pat")))"}
$result = Invoke-RestMethod -Uri $uri -Method Post -Body $body -ContentType "application/json" -Headers $headers
$result.workItems | ForEach-Object { Write-Host "$($_.id): $($_.url)" }

Azure Repos: Branch Policies and Pull Request Best Practices

Azure Repos hosts Git repositories with support for pull requests, branch policies, and code reviews. For production, branch policies are non-negotiable. Configure policies on the main branch (and release branches) to require: (1) a minimum number of reviewers, (2) successful build validation, (3) linked work items, and (4) comment resolution. Use the 'Require a minimum number of reviewers' policy with 'Reset code reviewer votes when new changes are pushed' to force re-review. Build validation should run a fast CI pipeline (lint, unit tests) within 5 minutes. Avoid running full integration tests in PR validation—they belong in the CI pipeline after merge. Use the 'Automatically include reviewers' policy to assign based on file patterns (e.g., security team for *.cs files). For branching strategy, use trunk-based development: short-lived feature branches merged daily. Avoid long-lived release branches; instead, use feature flags.

trigger: none
pr:
  branches:
    include:
    - main

pool:
  vmImage: 'ubuntu-latest'

steps:
- script: dotnet build --configuration Release
  displayName: 'Build'
- script: dotnet test --configuration Release --no-build --logger trx
  displayName: 'Run unit tests'

Azure Pipelines: CI/CD with YAML and Multi-Stage

Azure Pipelines supports both classic (UI-based) and YAML pipelines. For production, use YAML—it's version-controlled, reviewable, and portable. A typical pipeline has stages: Build, Test, Deploy. Use multi-stage YAML to define environments (dev, staging, production) with approvals and gates. For CI, trigger on every push to main. For CD, use manual triggers or automatic triggers with conditions (e.g., only on tags). Use variables and variable groups for configuration. For secrets, use Azure Key Vault integration. Use templates to reuse common steps (e.g., 'dotnet build' template). Use 'dependsOn' to control stage order. Use 'condition' to skip stages (e.g., skip deploy if build fails). Use 'environment' to track deployments and set approvals. For complex deployments, use 'jobs' with 'deployment' strategy (runOnce, rolling, canary).

trigger:
- main

variables:
  buildConfiguration: 'Release'

stages:
- stage: Build
  jobs:
  - job: BuildJob
    pool:
      vmImage: 'ubuntu-latest'
    steps:
    - task: DotNetCoreCLI@2
      inputs:
        command: 'build'
        projects: '**/*.csproj'
        arguments: '--configuration $(buildConfiguration)'
    - task: DotNetCoreCLI@2
      inputs:
        command: 'test'
        projects: '**/*Tests.csproj'
        arguments: '--configuration $(buildConfiguration) --no-build'
    - task: PublishBuildArtifacts@1
      inputs:
        PathtoPublish: '$(Build.ArtifactStagingDirectory)'
        ArtifactName: 'drop'

- stage: Deploy
  dependsOn: Build
  condition: succeeded()
  jobs:
  - deployment: DeployWeb
    pool:
      vmImage: 'ubuntu-latest'
    environment: 'production'
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureWebApp@1
            inputs:
              azureSubscription: 'my-service-connection'
              appName: 'my-app'
              package: '$(Pipeline.Workspace)/drop/**/*.zip'

Integrating Boards, Repos, and Pipelines for Traceability

The power of Azure DevOps is the integration between services. When you link a work item to a commit (using 'AB#{id}' in commit message), the work item automatically updates. When you link a work item to a PR, the PR shows the work item context. When a PR merges, the pipeline can auto-resolve the work item. To set this up: (1) In the pipeline, use the 'Update work item' task or set 'Automatically link work items' in the PR trigger. (2) Use the 'AB#{id}' syntax in commit messages. (3) Configure branch policies to require linked work items. This creates an audit trail: from requirement (work item) to code change (commit) to deployment (pipeline run). For compliance, you can query the Analytics service to show which work items were deployed in a release. Use the 'Release' artifact in Boards to track deployments per work item.

git commit -m "Add user login feature

AB#1234 - Implement OAuth login
AB#1235 - Add login page"

Managing Secrets and Variables in Pipelines

Never hardcode secrets in YAML files. Use Azure Pipelines library variable groups, Azure Key Vault, or the 'secret' variable type. For variable groups, link them to Key Vault for automatic secret rotation. In YAML, reference secrets as $(secretName). To use Key Vault: (1) Create a Key Vault, (2) Add secrets, (3) In Azure DevOps, create a service connection to Key Vault, (4) In the pipeline, use the 'AzureKeyVault' task to download secrets. Alternatively, use variable groups linked to Key Vault. For non-secret variables, use variable groups or template parameters. Use 'condition' to load different variable groups per environment (e.g., dev vs prod). Never log secret values—use 'logging command' with 'setvariable' but mark as secret. Use the 'Allow scripts to access the OAuth token' option only when necessary.

variables:
- group: 'Production-Secrets'

steps:
- task: AzureKeyVault@2
  inputs:
    azureSubscription: 'my-service-connection'
    KeyVaultName: 'my-keyvault'
    SecretsFilter: '*'
    RunAsPreJob: false

- script: echo "$(MySecret)" | sed 's/./& /g'  # Never do this in production!
  displayName: 'Echo secret (masked)'
  env:
    MySecret: $(MySecret)

Testing Strategies in Pipelines: Unit, Integration, and E2E

A robust pipeline runs tests at multiple levels. Unit tests run in PR validation (fast, <5 min). Integration tests run after merge (medium, <15 min). End-to-end tests run before deployment (slow, <30 min). Use 'dotnet test' with '--filter' to run specific test categories. For integration tests, use Docker containers for dependencies (e.g., SQL Server, Redis). For E2E tests, use Playwright or Selenium. Publish test results using 'PublishTestResults@2' task. Use 'testRunTitle' to differentiate runs. For flaky tests, use 'rerunFailedTests' or 'retryCountOnTaskFailure'. Use 'condition' to run tests only on certain branches. For code coverage, use 'dotnet test --collect:"XPlat Code Coverage"' and publish with 'PublishCodeCoverageResults@1'. Set coverage thresholds to fail the build if below target.

stages:
- stage: Test
  jobs:
  - job: UnitTests
    steps:
    - script: dotnet test --configuration Release --filter "Category=Unit" --logger trx
      displayName: 'Run unit tests'
    - task: PublishTestResults@2
      inputs:
        testResultsFormat: 'VSTest'
        testResultsFiles: '**/*.trx'
        testRunTitle: 'Unit Tests'

  - job: IntegrationTests
    dependsOn: UnitTests
    condition: succeeded()
    steps:
    - script: docker-compose up -d
      displayName: 'Start dependencies'
    - script: dotnet test --configuration Release --filter "Category=Integration" --logger trx
      displayName: 'Run integration tests'
    - script: docker-compose down
      displayName: 'Stop dependencies'

Deployment Strategies: Blue-Green, Canary, and Rolling

Azure Pipelines supports multiple deployment strategies via the 'deployment' job. For production, use blue-green or canary to minimize risk. Blue-green: maintain two identical environments (blue and green). Deploy to the inactive environment, run smoke tests, then swap traffic. In YAML, use 'strategy: runOnce' with 'swap' step. Canary: deploy to a subset of instances (e.g., 10%), monitor, then roll out to rest. Use 'strategy: canary' with increments (10%, 50%, 100%). Rolling: update instances gradually. Use 'strategy: rolling' with 'maxParallel' to control batch size. For each strategy, define 'preDeploy', 'deploy', 'routeTraffic', 'postRouteTraffic', and 'on:failure' hooks. Use 'environment' with approvals for production. Use 'deployment' output variables to pass information between stages.

jobs:
- deployment: CanaryDeploy
  pool:
    vmImage: 'ubuntu-latest'
  environment: 'production'
  strategy:
    canary:
      increments: [10, 50, 100]
      preDeploy:
        steps:
        - script: echo 'Pre-deploy checks'
      deploy:
        steps:
        - task: AzureWebApp@1
          inputs:
            azureSubscription: 'my-service-connection'
            appName: 'my-app'
            package: '$(Pipeline.Workspace)/drop/**/*.zip'
      routeTraffic:
        steps:
        - script: echo 'Route 10% traffic'
      postRouteTraffic:
        steps:
        - script: echo 'Run smoke tests'
      on:
        failure:
          steps:
          - script: echo 'Rollback'
        success:
          steps:
          - script: echo 'Deployment successful'

Monitoring and Feedback Loops with Azure DevOps

Deployment is not the end. Use Azure Monitor, Application Insights, and Azure DevOps Analytics to close the feedback loop. In pipelines, add tasks to run post-deployment smoke tests and check health endpoints. Use 'AzureMonitor@1' task to query metrics. Use 'ApplicationInsights@1' to check for anomalies. If a deployment causes increased error rates, the pipeline can automatically rollback. Use 'conditions' to check metrics before proceeding to next stage. For long-term trends, use Azure DevOps Analytics to track deployment frequency, lead time, change failure rate, and mean time to recovery (DORA metrics). Create dashboards in Azure DevOps or Power BI. Use 'work item queries' to track bugs found in production. Link incidents to work items for traceability.

$url = "https://my-app.azurewebsites.net/health"
try {
    $response = Invoke-WebRequest -Uri $url -TimeoutSec 10
    if ($response.StatusCode -eq 200) {
        Write-Host "Health check passed"
    } else {
        Write-Error "Health check failed with status $($response.StatusCode)"
        exit 1
    }
} catch {
    Write-Error "Health check failed: $_"
    exit 1
}

Scaling Azure DevOps for Large Teams and Organizations

As teams grow, Azure DevOps needs governance. Use 'Azure DevOps Projects' to organize repositories and pipelines. Use 'Azure DevOps Services' hierarchy: Organization -> Project -> Team. Each team has its own area path and board. Use 'Azure DevOps Extensions' for custom needs (e.g., 'Pull Request Size', 'Sprint Retrospective'). For security, use 'Azure AD' for authentication and 'Azure DevOps Security Groups' for permissions. Use 'Azure DevOps Auditing' to track changes. For compliance, use 'Azure Policy' to enforce branch policies across projects. Use 'Azure DevOps REST API' for automation (e.g., create work items from external systems). For large monorepos, use 'Azure Repos' with 'Scaled Git' (GVFS) or 'Azure DevOps Server' for on-premises. Use 'Azure Pipelines' with 'parallel jobs' and 'self-hosted agents' for performance.

$pat = "$(System.AccessToken)"
$org = "your-org"
$project = "your-project"
$teamName = "Backend Team"
$uri = "https://dev.azure.com/$org/_apis/projects/$project/teams?api-version=6.0"
$body = @{
  name = $teamName
  description = "Backend development team"
} | ConvertTo-Json
$headers = @{Authorization = "Basic $([Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(":$pat")))"}
$result = Invoke-RestMethod -Uri $uri -Method Post -Body $body -ContentType "application/json" -Headers $headers
Write-Host "Team created: $($result.name)"

Common Pitfalls and How to Avoid Them

Even experienced teams fall into traps. (1) Pipeline as an afterthought: Don't write pipelines after code is done. Design CI/CD from day one. (2) Hardcoded values: Use variables and variable groups. (3) Ignoring security: Use service connections with least privilege, not personal access tokens. (4) No rollback plan: Always have a rollback script. (5) Overly complex YAML: Use templates and keep pipelines simple. (6) Not testing deployments: Use 'deployment' strategy with smoke tests. (7) Ignoring feedback: Monitor and act on DORA metrics. (8) Branch pollution: Delete branches after merge. (9) Large PRs: Enforce size limits. (10) No code reviews: Require at least one reviewer. Avoid these by establishing a DevOps playbook and conducting regular retrospectives.

# Simple template to avoid repetition
parameters:
- name: buildConfiguration
  type: string
  default: 'Release'

steps:
- task: DotNetCoreCLI@2
  inputs:
    command: 'build'
    projects: '**/*.csproj'
    arguments: '--configuration ${{ parameters.buildConfiguration }}'

Next Steps: Continuous Improvement with Azure DevOps

Azure DevOps is not a set-and-forget tool. Continuously improve your processes. Use the 'Retrospective' extension to capture feedback. Review DORA metrics monthly. Experiment with new features: 'Pipeline decorators', 'YAML templates', 'Environments with Kubernetes'. For advanced scenarios, use 'Azure DevOps REST API' to integrate with other tools (e.g., Jira, Slack). Consider 'Azure DevOps Server' for on-premises compliance. Stay updated with Microsoft's release notes. Join the Azure DevOps community. Remember: the goal is not to use all features, but to use the right features for your team. Start small, iterate, and measure. The best DevOps practice is the one that reduces friction and increases delivery speed without sacrificing quality.

# Get deployment frequency via REST API
$uri = "https://dev.azure.com/$org/$project/_apis/build/definitions?api-version=6.0"
$definitions = Invoke-RestMethod -Uri $uri -Headers $headers
$definitions.value | ForEach-Object {
    $defId = $_.id
    $buildsUri = "https://dev.azure.com/$org/$project/_apis/build/builds?definitions=$defId&resultFilter=succeeded&api-version=6.0"
    $builds = Invoke-RestMethod -Uri $buildsUri -Headers $headers
    Write-Host "Definition $($_.name): $($builds.count) successful builds in last 30 days"
}

Azure Artifacts: Private Package Management with Upstream Sources

Azure Artifacts provides a private package registry for NuGet, npm, Maven, Python, and Universal Packages. The core concept is the feed — an organizational construct that stores and manages packages. For production, use organization-scoped feeds for shared libraries and project-scoped feeds for strict isolation. Enable upstream sources to proxy public registries (NuGet.org, npmjs.com, PyPI) through your feed, caching packages for offline resilience and consistent builds. This eliminates the need to manage multiple registry URLs in configuration files. Use feed views (@Local, @Prerelease, @Release) as quality gates: promote packages through views as they pass validation stages. Set retention policies to keep only the last N versions (e.g., 25) with download protection (e.g., 30 days) to control storage costs. Production packages promoted to @Release are exempt from retention. For versioning, use GitVersion or semantic versioning (SemVer) with build metadata. In CI/CD, use the NuGetAuthenticate@1, npmAuthenticate@0, or PipAuthenticate@1 tasks to inject credentials automatically. Cross-project package consumption requires the build service identity to have Reader role on the target feed.

steps:
- task: DotNetCoreCLI@2
  displayName: 'Restore NuGet packages'
  inputs:
    command: 'restore'
    projects: '**/*.csproj'
    feedsToUse: 'select'
    vstsFeed: 'my-organization-scoped-feed'

- task: npmAuthenticate@0
  displayName: 'Authenticate npm'
  inputs:
    workingFile: '.npmrc'

- task: PipAuthenticate@1
  displayName: 'Authenticate pip'
  inputs:
    artifactFeeds: 'my-org-feed'

Azure Test Plans: Manual and Exploratory Testing at Scale

Azure Test Plans provides manual testing, exploratory testing, and continuous testing capabilities integrated with Azure Boards. Use test plans to organize test cases into test suites, assign testers, and track execution progress. Test cases link to work items (user stories, bugs) for traceability. For production, create test plans per release or sprint, with test suites for functional areas. Use shared steps and shared parameters to reduce duplication. The exploratory testing extension (free for stakeholders) allows testers to capture rich data — screenshots, screen recordings, and comments — while exploring the application without pre-written scripts. Results include bugs automatically created with steps-to-reproduce. For continuous testing, run automated tests from Azure Pipelines and publish results to Test Plans using the 'Publish Test Results' task. This gives a single pane of glass for both manual and automated test results. Use test analytics to track pass rates, test duration, and flaky tests. For compliance, export test results or use the REST API to integrate with third-party tools.

$pat = "$(System.AccessToken)"
$org = "your-org"
$project = "your-project"
$uri = "https://dev.azure.com/$org/$project/_apis/test/plans?api-version=6.0"
$body = @{
  name = "Sprint 42 Release Test Plan"
  area = @{ name = "Sprint 42" }
  iteration = "Sprint 42"
  description = "Manual and exploratory tests for Sprint 42 release"
} | ConvertTo-Json
$headers = @{Authorization = "Basic $([Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(":$pat")))"}
$result = Invoke-RestMethod -Uri $uri -Method Post -Body $body -ContentType "application/json" -Headers $headers
Write-Host "Test plan created: $($result.id)"

Self-Hosted vs Microsoft-Hosted Agents: Choosing the Right Build Infrastructure

Azure Pipelines runs jobs on agents — either Microsoft-hosted (managed by Azure) or self-hosted (managed by you). Microsoft-hosted agents come pre-configured with popular tools (Git, .NET, Node, Python, Docker) and are zero-maintenance, but have limits: 60 minutes per job (free tier), 10 concurrent jobs, and no custom software installation. Self-hosted agents give you full control: install any software, unlimited job duration, access to on-premises resources, and lower cost at high volume. In production, use Microsoft-hosted for standard CI (build, unit tests) and self-hosted for tasks requiring custom dependencies, long runtimes, or network access to internal resources. Deploy self-hosted agents as scalable virtual machine scale sets (VMSS) for auto-scaling. Use agent pools to organize agents by purpose (e.g., Linux build pool, Windows test pool). For security, run self-hosted agents in a separate subscription with network isolation. Never install self-hosted agents on your local machine — always use dedicated VMs or containers. Monitor agent health with the Agent Health dashboard and set up alerts for offline agents.

# Create a PAT for agent registration
# Install agent on Ubuntu VM
mkdir myagent && cd myagent
wget https://vstsagentpackage.azureedge.net/agent/3.240.0/azagent.tar.gz
tar zxvf azagent.tar.gz

# Configure and run
./config.sh --unattended \
  --url "https://dev.azure.com/your-org" \
  --auth pat --token "$PAT" \
  --pool "Linux-Prod" \
  --agent "prod-agent-01" \
  --replace

# Install as a service
sudo ./svc.sh install
sudo ./svc.sh start