Azure DevOps Tutorial: Learn CI/CD from Scratch (2026)
I remember the dark ages before CI/CD. Deployments meant checking a spreadsheet to see who had the latest build, copying files via RDP to a staging server, and praying nothing broke. Our release cycle was measured in weeks, and rollbacks meant digging through backup tapes. Azure DevOps changed all of that. The first time I saw a pull request trigger an automated build, run all tests, and deploy to production without human intervention, I knew there was no going back.
Azure DevOps is Microsoft's DevOps platform providing developer services for planning, collaborating, building, testing, and deploying applications. It started as Visual Studio Team Services (VSTS) and evolved into a comprehensive suite including Azure Repos, Azure Pipelines, Azure Boards, Azure Test Plans, and Azure Artifacts. This tutorial covers the essential workflows for setting up continuous integration and delivery pipelines.
Azure Repos: Git Branching and Pull Requests
Azure Repos hosts Git repositories with enterprise features like branch policies, pull request comments, and code reviewers. Branch policies enforce quality gates — requiring a minimum number of reviewers, passing builds, or linked work items before a PR can be completed. The branch policy configuration is a key governance tool.
A typical branching strategy uses main (or master) as the stable release branch, develop for integration, and feature branches for individual work. Release branches stabilize a specific version, and hotfix branches patch production issues. Azure Repos integrates with Azure Pipelines so every push to a feature branch triggers a build.
git checkout -b feature/user-authentication
git add .
git commit -m "Add user login and registration endpoints"
git push origin feature/user-authentication
az repos pr create --repository MyRepo --source-branch feature/user-authentication --target-branch main --title "Add user authentication" --description "Implements JWT-based login with refresh tokens"Azure Pipelines: YAML-Based CI/CD
Azure Pipelines defines build, test, and deployment processes as code using YAML. The azure-pipelines.yml file describes triggers, pool, variables, steps, and stages. Pipelines can be triggered by pushes, pull requests, schedules, or REST API calls. Each pipeline run executes one or more jobs across agents.
Multi-stage pipelines separate build, test, and deploy into distinct stages with approvals and gates. A typical pipeline builds the application, runs integration tests, deploys to staging for validation, and deploys to production after manual approval. Deployment jobs use environment resources that track which version is deployed.
trigger:
branches:
include:
- main
- develop
pool:
vmImage: 'ubuntu-latest'
stages:
- stage: Build
jobs:
- job: BuildApp
steps:
- task: DotNetCoreCLI@2
inputs:
command: 'build'
projects: '**/*.csproj'
- task: DotNetCoreCLI@2
inputs:
command: 'test'
projects: '**/*Tests.csproj'
- task: PublishBuildArtifacts@1Azure Boards: Work Item Tracking and Agile Planning
Azure Boards provides work tracking with customizable backlogs, boards, and sprints. Work items — Epics, Features, User Stories, Tasks, Bugs — form a hierarchy connecting business initiatives to day-to-day work. Boards visualize the workflow as columns (To Do, In Progress, Done).
The integration between Boards and Repos is where Azure DevOps shines. Linking a work item in a commit message automatically creates a link between the commit and the work item. Sprint planning tools calculate capacity, track burndown, and alert teams when scope exceeds capacity.
az boards work-item create --title "Implement OAuth2 login" --type "User Story" --assigned-to "user@contoso.com" --iteration "Sprint 3"
git commit -m "Implement OAuth2 login (AB#342)"
az boards work-item update --id 342 --state "Resolved"Release Gates, Approvals, and Deployment Strategies
Release pipelines control how artifacts are deployed across environments. Each environment can require approvals — specific users or groups must approve before deployment proceeds. Deployment gates evaluate health metrics like error rates and load before allowing the next stage.
Deployment strategies determine how new versions are rolled out. Rolling updates gradually replace instances. Blue-green deployments maintain two identical environments and switch traffic. Canary deployments route a small percentage of traffic to the new version. Azure App Service slots support swap with preview for zero-downtime deployments.
stages:
- stage: DeployStaging
jobs:
- deployment: Deploy
environment: 'staging'
strategy:
runOnce:
deploy:
steps:
- task: AzureWebApp@1
inputs:
azureSubscription: 'MyAzureConnection'
appName: 'MyApp-Staging'
package: '$(Pipeline.Workspace)/drop/*.zip'
- stage: DeployProduction
dependsOn: DeployStaging
condition: succeeded()
jobs:
- deployment: Deploy
environment: 'production'
strategy:
canary:
increments: [10, 50, 100]Azure Test Plans and Quality Gates
Azure Test Plans supports manual and exploratory testing integrated with the development lifecycle. Test plans organize test suites and test cases linked to requirements. Manual testers execute test steps, capture screenshots, and log bugs directly from the test runner.
Quality gates in pipelines enforce metrics before promotion. A test pass rate below 90% blocks promotion from staging to production. Code coverage thresholds ensure new code is adequately tested. Vulnerability scanning checks dependencies for known vulnerabilities.
- task: VSTest@2
inputs:
testSelector: 'testAssemblies'
testAssemblyVer2: |
**\*Tests.dll
searchFolder: '$(System.DefaultWorkingDirectory)'
codeCoverageEnabled: true
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
- task: PublishCodeCoverageResults@1
inputs:
codeCoverageTool: 'Cobertura'
summaryFileLocation: '$(System.DefaultWorkingDirectory)/**/coverage.cobertura.xml'Azure Artifacts and Package Management
Azure Artifacts provides private package feeds for NuGet, npm, Maven, Python, and Universal packages. Feeds control who can publish and consume packages, with upstream sources caching packages from public registries for reliability. A development team publishes internal libraries as NuGet packages consumed by multiple applications.
Package promotion moves packages through feeds as they mature. A package published to the @Local feed is for development. Promoting it to the @Release feed signals production-readiness. Retention policies automatically delete older versions to manage storage.
az artifacts feed create --name MyTeamFeed --organization https://dev.azure.com/myorg
dotnet pack MyLib.csproj --configuration Release -o ./nupkg
dotnet nuget push ./nupkg/*.nupkg --source https://pkgs.dev.azure.com/myorg/MyTeamFeed/_packaging/MyTeamFeed/nuget/v3/index.json --api-key az
az artifacts feed upstream add --feed MyTeamFeed --upstream-name nuget-official --upstream-type Public --location https://api.nuget.org/v3/index.jsonFrequently Asked Questions
What is the difference between Azure DevOps and GitHub?
Azure DevOps is a comprehensive enterprise DevOps platform with Azure Boards, Test Plans, and Artifacts. GitHub focuses on code hosting with Actions for CI/CD. Many organizations use both.
Should I use classic pipelines or YAML pipelines?
YAML pipelines are recommended for all new development. They are version-controlled, reviewable in pull requests, and portable across projects.
How do I handle secrets and connection strings in pipelines?
Use Azure Key Vault to store secrets and link them to pipeline variable groups. Mark variables as secret. Never hardcode secrets in YAML files.
What is a self-hosted agent and when should I use one?
Self-hosted agents run on your own machines with custom software. Use them when you need specific tools, more disk space, or access to on-premises resources.
Originally published on Ayodhyyya. Last updated June 1, 2026.