Azure DevOps Integration
Azure DevOps is Microsoft’s suite for planning, coding, building and releasing software, with built-in Azure integration.
On this page · 5 min · Advanced
On this page
- Learning objectives
- Explanation
- Code example
- Step by step
- Real-world use
- Common mistakes
- Best practices
- Remember this
- Practice exercise
- Mini quiz
- Related topics
- My notes
- Reading time
- 5 min
- Difficulty
- Advanced
- Updated
- Oct 29, 2026
Related tutorials
Interview questions
Learning objectives#
- Name the five Azure DevOps services
- Connect a pipeline to Azure with a service connection
- Write a basic azure-pipelines.yml
- Compare Azure DevOps and GitHub Actions
Explanation#
Boards (work items and sprints), Repos (Git), Pipelines (CI/CD), Test Plans (manual and exploratory testing) and Artifacts (package feeds) can be used together or individually.
A service connection stores how a pipeline authenticates to Azure. Workload identity federation lets pipelines get short-lived tokens without storing secrets.
Pipelines are defined in YAML in the repository, so changes are reviewed like code.
GitHub Actions offers similar CI/CD; many teams use GitHub for code and either tool for pipelines.
Code example: Build and deploy an ASP.NET Core API#
trigger: [main]
pool: { vmImage: ubuntu-latest }
steps:
- task: UseDotNet@2
inputs: { packageType: sdk, version: 9.x }
- script: dotnet test --configuration Release
displayName: Run tests
- script: dotnet publish src/Shop.Api -c Release -o $(Build.ArtifactStagingDirectory)
displayName: Publish
- task: AzureWebApp@1
inputs:
azureSubscription: sc-shop-prod # service connection (workload identity federation)
appName: app-shop-api
package: $(Build.ArtifactStagingDirectory)
Every push to main runs tests, publishes the API and deploys it to App Service. A failed test stops the deployment.
This example is illustrative. Copy or download it and run it in your own environment; the expected output is shown above.
Step-by-step explanation#
- trigger runs the pipeline on pushes to main.
- UseDotNet installs the .NET 9 SDK on the hosted agent.
- Tests run before publishing, so broken code never deploys.
- AzureWebApp deploys using the service connection — no credentials in the YAML.
Real-world use case#
Enterprise teams track work in Boards, review code in Repos and promote builds through dev → test → prod environments with approvals in Pipelines.
Common mistakes#
Use service connections and secret variables; YAML is visible to everyone with repo access.
Run tests before deploy steps so failures block releases.
Best practices#
- Use YAML pipelines in the repo
- Use workload identity federation for service connections
- Add environment approvals for production
- Cache dependencies to speed up builds
Remember this#
Boards · Repos · Pipelines · Test Plans · Artifacts.
Service connection = how the pipeline logs in to Azure.
Test before deploy — always.
Practice exercise#
Your task: Add a condition so the deploy step only runs on the main branch.
Show solution
- task: AzureWebApp@1
condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
Mini quiz#
Which Azure DevOps service runs CI/CD?
Want more? Practise all Microsoft Azure MCQs · Microsoft Azure interview questions
My notes#
Saved in this browser.