Azure DevOps Overview: Boards, Repos, and Pipelines

Azure DevOps is Microsoft’s platform for end-to-end software delivery. It bundles five distinct services — Boards, Repos, Pipelines, Artifacts, and Test Plans — under one organization URL. You can use all five together, or connect individual services to the rest of your toolchain. This page explains what each service does and how they connect.

How Azure DevOps is organized

Azure DevOps uses a hierarchy: Organization → Project → Services. An organization is your company or team’s root namespace (for example, dev.azure.com/contoso). Inside the organization you create projects. Each project gets its own Boards, Repos, Pipelines, Artifacts, and Test Plans. Projects are siloed — a pipeline in Project A cannot access a repo in Project B without explicit cross-project permissions.

# Azure CLI — install the Azure DevOps extension
az extension add --name azure-devops

# Set a default organization and project
az devops configure --defaults organization=https://dev.azure.com/contoso project=MyProject

# List projects in your organization
az devops project list

# Create a new project
az devops project create --name "NewProject" --visibility private

# Show project details
az devops project show --project MyProject

Azure Boards: work item tracking

Azure Boards is the project management layer. It gives you a backlog, sprints, a Kanban board, and a query engine for work items. Work item types (Epic, Feature, User Story, Task, Bug) follow a hierarchy. You link work items to pull requests and pipeline runs, so you can trace a feature from planning to deployment.

The process templates define your workflow. The three built-in templates are:

Agile. User Stories, Tasks, Bugs. The default for most software teams.
Scrum. Product Backlog Items, Tasks, Bugs. Aligned with the Scrum framework.
CMMI. Requirements, Change Requests, Issues. For compliance-heavy environments.

# Create a work item from the CLI
az boards work-item create \
  --type "User Story" \
  --title "Add health check endpoint to API" \
  --assigned-to "developer@contoso.com" \
  --area "MyProject\\Team A"

# Update work item state
az boards work-item update \
  --id 1234 \
  --state "Active"

# Query work items
az boards query \
  --wiql "SELECT [Id], [Title], [State] FROM workitems WHERE [System.WorkItemType] = 'Bug' AND [State] = 'Active'"

Azure Repos: git hosting

Azure Repos hosts git repositories inside your project. Each project can have multiple repos. You get branch policies, required reviewers, status checks from pipelines, and comment resolution rules — all configurable per branch.

A branch policy that requires a successful pipeline build and at least one approved review before merging to main is the most common configuration for production code.

# List repos in a project
az repos list --output table

# Create a new repo
az repos create --name "my-api"

# Clone the repo (standard git)
git clone https://contoso@dev.azure.com/contoso/MyProject/_git/my-api

# Create a branch policy requiring a build to pass before merging
az repos policy build create \
  --blocking true \
  --branch main \
  --build-definition-id 5 \
  --enabled true \
  --queue-on-source-update true \
  --repository-id $(az repos show --repository my-api --query id -o tsv) \
  --valid-duration 720

Azure Pipelines: CI/CD

Azure Pipelines is the CI/CD engine. Pipelines are defined as YAML files stored in your repo. There are two types: build pipelines (CI) that run on pull requests and commits, and release pipelines (CD) that deploy artifacts to environments. Modern Azure DevOps encourages combining both in a single multi-stage YAML pipeline.

# azure-pipelines.yml — a minimal multi-stage pipeline
trigger:
  branches:
    include:
      - main

pool:
  vmImage: 'ubuntu-latest'

stages:
  - stage: Build
    displayName: 'Build and Test'
    jobs:
      - job: BuildJob
        steps:
          - task: UseDotNet@2
            inputs:
              packageType: 'sdk'
              version: '8.x'

          - script: dotnet build --configuration Release
            displayName: 'Build'

          - script: dotnet test --no-build --configuration Release
            displayName: 'Test'

          - task: PublishBuildArtifacts@1
            inputs:
              pathToPublish: '$(Build.ArtifactStagingDirectory)'
              artifactName: 'drop'

  - stage: Deploy_Dev
    displayName: 'Deploy to Dev'
    dependsOn: Build
    condition: succeeded()
    jobs:
      - deployment: DeployDev
        environment: 'dev'
        strategy:
          runOnce:
            deploy:
              steps:
                - script: echo "Deploying to dev..."

Pipeline agents: Microsoft-hosted vs self-hosted

Every pipeline job runs on an agent — a machine that checks out code, runs steps, and reports results. You have two choices:

Microsoft-hosted agents. Ephemeral VMs managed by Microsoft. Available for Ubuntu, Windows, and macOS. You get a clean environment for every job. Free minutes are included; additional minutes are paid. Cannot access resources inside private VNets without additional configuration.
Self-hosted agents. VMs or containers you manage. Run inside your VNet, have access to private resources, can cache dependencies across runs. Require you to handle patching and scaling.

# Use a Microsoft-hosted agent
pool:
  vmImage: 'ubuntu-latest'   # or 'windows-latest', 'macOS-latest'

# Use a self-hosted agent pool
pool:
  name: 'MyPrivatePool'
  demands:
    - Agent.OS -equals Linux

# Register a self-hosted Linux agent
mkdir ~/myagent && cd ~/myagent
curl -O https://vstsagentpackage.azureedge.net/agent/3.236.1/vsts-agent-linux-x64-3.236.1.tar.gz
tar zxvf vsts-agent-linux-x64-3.236.1.tar.gz

# Configure the agent
./config.sh \
  --url https://dev.azure.com/contoso \
  --auth PAT \
  --token <your-pat-token> \
  --pool MyPrivatePool \
  --agent my-agent-01 \
  --acceptTeeEula

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

Azure Artifacts: package management

Azure Artifacts hosts NuGet, npm, Maven, Python, and generic packages. Pipelines publish packages to feeds during the build stage and download them during deployment. Feeds can be scoped to a project or shared across the entire organization.

# Publish a NuGet package to Azure Artifacts
- task: NuGetCommand@2
  displayName: 'Pack NuGet package'
  inputs:
    command: 'pack'
    packagesToPack: '**/*.csproj'
    versioningScheme: 'byBuildNumber'

- task: NuGetCommand@2
  displayName: 'Push to Artifacts feed'
  inputs:
    command: 'push'
    packagesToPush: '$(Build.ArtifactStagingDirectory)/**/*.nupkg'
    nuGetFeedType: 'internal'
    publishVstsFeed: 'MyProject/MyFeed'

Service connections: linking Azure DevOps to Azure

A service connection stores the credentials a pipeline uses to authenticate to external services. To deploy to Azure from a pipeline, you create an Azure Resource Manager service connection — it creates a Service Principal in your Azure AD tenant and stores its credentials in Azure DevOps securely. Pipelines reference the connection by name.

# Reference a service connection in a pipeline task
- task: AzureWebApp@1
  displayName: 'Deploy to App Service'
  inputs:
    azureSubscription: 'My Azure Subscription'   # name of the service connection
    appType: 'webApp'
    appName: 'my-app-dev'
    package: '$(Pipeline.Workspace)/drop/**/*.zip'

Common mistakes

Giving service connections Contributor access at the subscription level. Pipelines only need access to the specific resource groups they deploy to. Scope service connection role assignments to resource groups or specific resources, not the entire subscription.
Not using environments for deployment gates. Deploying to production in a pipeline step with no human approval gate is risky. Create Azure DevOps Environments and configure required approvals — the pipeline will pause at the deployment stage until someone approves.
Storing pipeline YAML outside the repo it builds. When the pipeline definition lives in a separate repo from the application code, pull request builds stop working correctly and it becomes difficult to version pipeline changes alongside code changes. Keep azure-pipelines.yml in the same repo as your application.

Frequently asked questions

Is Azure DevOps the same as GitHub?

No. Azure DevOps is a separate Microsoft product focused on enterprise CI/CD and project management. GitHub is a code hosting platform that Microsoft also owns. Both can host git repositories and both support CI/CD (Azure Pipelines and GitHub Actions respectively). Many teams use GitHub for code hosting and Azure Pipelines for CI/CD, connecting them via a service connection.

Is Azure DevOps free?

Azure DevOps has a free tier: up to 5 users for Basic plan features, unlimited users for Stakeholder access (view and update work items only), free public pipelines, and 1,800 minutes per month of Microsoft-hosted agent time for private projects. Additional parallel jobs and minutes are paid.

Do I need to use all Azure DevOps services together?

No. Each Azure DevOps service is independent. Many teams use Azure Boards for tracking but host code on GitHub. Others use Azure Repos and Pipelines but skip Boards in favour of Jira. You can mix and match freely.

Last verified: 19 March 2026 Cloud services change frequently. Verify details against official documentation before making infrastructure decisions.