Microsoft Azure DevOps official documentation
Azure DevOps — Complete Guide for .NET Lead
1. What is Azure DevOps?
Azure DevOps is a set of services for planning, developing, testing, deploying, and monitoring software.
Think of a typical .NET project:
Developer
|
v
Write C# Code
|
v
Git Repository
|
v
Build
|
v
Unit Tests
|
v
Code Quality
|
v
Deploy to DEV
|
v
Testing
|
v
Deploy to QA
|
v
Deploy to Production
|
v
Azure Monitor / Application Insights
Azure DevOps helps automate this entire process.
2. Main Azure DevOps Services
You should remember these:
Azure DevOps
|
+-- Azure Repos
|
+-- Azure Pipelines
|
+-- Azure Boards
|
+-- Azure Test Plans
|
+-- Azure Artifacts
Easy way to remember
| Service | Purpose |
|---|---|
| Azure Repos | Source Code |
| Azure Pipelines | CI/CD |
| Azure Boards | Work Management |
| Azure Test Plans | Testing |
| Azure Artifacts | Package Management |
3. Real-Time Project
Let's take a real enterprise application:
Angular Frontend
|
v
ASP.NET Core Web API
|
+---- Azure SQL
|
+---- Azure Service Bus
|
+---- Azure Functions
|
+---- Azure Storage
Developers work on:
C#
Angular
SQL
Azure
Now imagine 10 developers working on the same project.
Azure DevOps provides the platform for:
Planning
↓
Coding
↓
Pull Request
↓
Review
↓
Build
↓
Unit Tests
↓
Security/Quality checks
↓
Deployment
↓
Monitoring
4. Azure Repos
Azure Repos provides Git repositories for source control.
Example:
MyCompany
|
+-- OrderManagement
|
+-- PaymentService
|
+-- InventoryService
You can use:
git clone
git pull
git push
git branch
git merge
just like other Git hosting platforms.
5. Typical Git Workflow
Suppose you are developing an Order API.
You shouldn't directly modify the production branch.
Instead:
main
|
+---- feature/order-api
Developer:
git checkout -b feature/order-api
Develop code:
OrderController.cs
OrderService.cs
OrderRepository.cs
Then:
git add .
git commit -m "Add order API"
git push origin feature/order-api
Then create:
Pull Request
6. Pull Request
The PR process is very important for a Lead.
Developer
|
v
Feature Branch
|
v
Pull Request
|
+---- Code Review
+---- Build
+---- Unit Tests
+---- Quality Checks
|
v
Approve
|
v
Merge
A Lead should establish policies such as:
Minimum reviewers
Build validation
Linked work items
No direct pushes to main
Required checks
Branch naming conventions
7. Branching Strategy
For many enterprise projects:
main
|
+-- develop
|
+-- feature/order
|
+-- feature/payment
|
+-- bugfix/order
Another common approach is trunk-based development:
main
|
+-- short-lived feature branch
|
+-- short-lived feature branch
|
+-- short-lived feature branch
Lead-level point
Don't say:
"Git Flow is always the best."
Instead:
"I choose the branching strategy based on release frequency, team size, deployment model, and whether we use feature flags or continuous delivery."
That's a stronger architectural answer.
8. Azure Boards
Azure Boards is used to manage work.
Typical hierarchy:
Epic
|
+-- Feature
|
+-- User Story
|
+-- Task
+-- Bug
Example:
Epic:
E-Commerce Platform
Feature:
Order Management
User Story:
As a customer, I want to place an order.
Tasks:
- Create Order API
- Create Order table
- Add validation
- Write unit tests
- Create Angular UI
9. Agile Sprint
Example:
Sprint 1
------------------------
Order API
Payment API
Login
Customer API
Azure Boards helps track:
To Do
↓
In Progress
↓
Code Review
↓
Testing
↓
Done
10. Azure Pipelines
This is probably the most important Azure DevOps feature for a .NET Lead.
Azure Pipelines automates:
Build
Test
Package
Deploy
This is called CI/CD.
11. What is CI?
Continuous Integration
Developers frequently merge code into the shared repository.
Every change triggers:
Git Push
↓
Pipeline
↓
Restore
↓
Build
↓
Unit Test
↓
Quality Checks
If build/test fails:
Pipeline FAILED
The developer fixes it before the change progresses.
12. What is CD?
Continuous Delivery/Deployment
After successful CI:
Build
↓
Test
↓
Deploy DEV
↓
Deploy QA
↓
Approval
↓
Deploy Production
13. Complete CI/CD Pipeline
For a .NET application:
Developer
|
v
Azure Repos
|
v
Pull Request
|
v
Build Validation
|
+----------+----------+
| |
v v
dotnet build dotnet test
| |
+----------+----------+
|
v
Create Artifact
|
v
DEV
|
v
Integration Test
|
v
QA
|
v
Approval/Gate
|
v
Production
|
v
Application Insights
This is a very strong diagram to explain during interviews.
14. Azure Pipeline YAML
A basic .NET pipeline can look like:
trigger:
- main
pool:
vmImage: 'ubuntu-latest'
variables:
buildConfiguration: 'Release'
steps:
- task: UseDotNet@2
inputs:
packageType: 'sdk'
version: '9.x'
- script: dotnet restore
displayName: 'Restore'
- script: dotnet build --configuration $(buildConfiguration) --no-restore
displayName: 'Build'
- script: dotnet test --configuration $(buildConfiguration) --no-build
displayName: 'Run Unit Tests'
- script: dotnet publish \
--configuration $(buildConfiguration) \
--output $(Build.ArtifactStagingDirectory)
displayName: 'Publish'
- task: PublishBuildArtifacts@1
inputs:
pathToPublish: '$(Build.ArtifactStagingDirectory)'
artifactName: 'drop'
The exact task versions and recommended YAML patterns can evolve, so use Microsoft's current task documentation when building a production pipeline.
15. Let's Understand the Pipeline
Step 1 — Trigger
trigger:
- main
Means:
Run the pipeline when changes are pushed to
main.
Step 2 — Agent
pool:
vmImage: 'ubuntu-latest'
Azure DevOps provides an agent to execute pipeline steps.
Conceptually:
Azure DevOps
|
v
Build Agent
|
+-- Restore
+-- Build
+-- Test
+-- Publish
16. Restore
- script: dotnet restore
Restores NuGet dependencies.
17. Build
- script: dotnet build --configuration Release
Compiles the application.
If C# has errors:
Build FAILED
The deployment doesn't continue.
18. Unit Testing
- script: dotnet test
Suppose:
100 Tests
98 Passed
2 Failed
Pipeline:
FAILED
This prevents broken code from moving forward.
19. Publish
dotnet publish
Creates deployable output.
Conceptually:
Source Code
↓
Build
↓
Publish
↓
Artifact
20. What is an Artifact?
An artifact is the output produced by the build that can be used later by deployment stages.
Example:
Build
|
v
drop.zip
Then:
drop.zip
|
+---- DEV
|
+---- QA
|
+---- PROD
A key Lead-level principle is:
Build once, deploy the same artifact through environments.
You don't want to rebuild differently for production.
21. Multi-Stage Pipeline
A better enterprise pipeline:
stages:
- stage: Build
jobs:
- job: Build
steps:
- script: dotnet restore
- script: dotnet build --configuration Release
- script: dotnet test --configuration Release
- script: dotnet publish \
--configuration Release \
--output $(Build.ArtifactStagingDirectory)
- publish: $(Build.ArtifactStagingDirectory)
artifact: drop
- stage: DeployDev
dependsOn: Build
jobs:
- deployment: Deploy
environment: Dev
strategy:
runOnce:
deploy:
steps:
- download: current
artifact: drop
- stage: DeployQA
dependsOn: DeployDev
jobs:
- deployment: Deploy
environment: QA
strategy:
runOnce:
deploy:
steps:
- download: current
artifact: drop
This demonstrates the concept:
Build
↓
Artifact
↓
DEV
↓
QA
↓
PROD
22. Environments
Azure DevOps environments represent deployment targets such as:
DEV
QA
UAT
PROD
Example:
Build
|
v
DEV
|
v
QA
|
v
UAT
|
v
PROD
23. Production Approval
Suppose your pipeline reaches:
Deploy Production
You can require an approval:
Pipeline
|
v
Production
|
Approval required
|
v
Manager/Lead approves
|
v
Deployment
This is important for controlled enterprise releases.
24. Variable Groups
Don't hard-code environment configuration into YAML.
Bad:
SqlConnectionString: "Server=..."
Instead, use variables/configuration mechanisms.
Example:
Variable Group
|
+-- Dev
+-- QA
+-- Prod
Then:
DEV → Dev configuration
QA → QA configuration
PROD → Prod configuration
For sensitive secrets, prefer Azure Key Vault integration rather than plain pipeline variables wherever appropriate.
25. Azure Key Vault + Azure DevOps
A strong enterprise architecture:
Azure DevOps Pipeline
|
v
Azure Key Vault
|
+---- SQL connection information
+---- API secrets
+---- Certificates
+---- Other secrets
The pipeline doesn't need secrets embedded in source code.
26. Azure DevOps + App Service
Suppose your application is deployed to:
Azure App Service documentation
Architecture:
Azure Repos
|
v
Azure Pipeline
|
v
Build
|
v
Test
|
v
Artifact
|
v
Azure App Service
27. Azure DevOps + Azure Functions
Exactly the same principle:
Git
|
v
Azure Pipeline
|
+-- Build
+-- Test
+-- Package
|
v
Azure Function
28. Azure DevOps + AKS
For containerized microservices:
Developer
|
v
Azure Repos
|
v
Azure Pipeline
|
+-- Build .NET
+-- Test
+-- Docker Build
+-- Push Image
|
v
Azure Container Registry
|
v
AKS
This connects several Azure services you should know as a .NET Lead.
29. Docker + Azure DevOps
Dockerfile:
FROM mcr.microsoft.com/dotnet/aspnet:9.0 AS base
WORKDIR /app
EXPOSE 8080
FROM mcr.microsoft.com/dotnet/sdk:9.0 AS build
WORKDIR /src
COPY . .
RUN dotnet restore
RUN dotnet publish \
-c Release \
-o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "OrderApi.dll"]
Pipeline:
Code
↓
Build
↓
Docker Image
↓
ACR
↓
AKS
30. Azure Container Registry
ACR stores container images.
Azure DevOps
|
v
docker build
|
v
Docker Image
|
v
Azure Container Registry
|
v
AKS
Example image:
mycompany.azurecr.io/order-api:1.0.0
31. Infrastructure as Code
A Lead should know that infrastructure shouldn't always be manually created in the Azure Portal.
Use:
Bicep
ARM templates
Terraform
Conceptually:
Infrastructure Code
|
v
Azure DevOps Pipeline
|
v
Azure Resources
Example:
Bicep
↓
App Service
↓
SQL
↓
Service Bus
↓
Key Vault
↓
Application Insights
This gives you repeatable environments.
32. Deployment Strategies
You should know these concepts.
Blue-Green
Production
|
+-- Blue
|
+-- Green
Deploy to Green and switch traffic when validated.
Canary
Users
|
+---- 95% → Version 1
|
+---- 5% → Version 2
Monitor Version 2.
If healthy:
5%
↓
25%
↓
50%
↓
100%
Rolling
Gradually replace old instances with new ones.
These strategies are particularly relevant to App Service, AKS and modern deployment architectures.
33. CI/CD Security
Your pipeline should include:
Code
↓
Build
↓
Unit Tests
↓
Security Scan
↓
Dependency Scan
↓
Quality Checks
↓
Artifact
↓
Deployment
A Lead should think about:
Secret management
Least privilege
Service connections
Branch policies
Dependency vulnerabilities
Container image scanning
Approval controls
Audit logs
34. Service Connections
Azure DevOps needs permission to deploy to Azure.
Conceptually:
Azure DevOps
|
| Service Connection
v
Azure Subscription
|
+---- App Service
+---- Function
+---- ACR
+---- AKS
Use appropriate identity-based authentication and least privilege rather than broadly granting excessive permissions.
35. Self-Hosted vs Microsoft-Hosted Agents
Microsoft-hosted agent
Azure DevOps provides the machine.
Pipeline
|
v
Microsoft-hosted Agent
Advantages:
Easy setup
Clean environment
Microsoft-managed infrastructure
Self-hosted agent
Your organization manages the agent.
Pipeline
|
v
Company Agent
Useful when you need:
Private network access
Special software
Internal systems
Custom build environments
36. Azure DevOps + Private Network
Suppose your SQL server is private:
Azure DevOps
|
X
Public Internet
You may need an appropriate self-hosted agent/network architecture.
Azure DevOps
|
v
Self-hosted Agent
|
v
VNet
|
v
Private SQL
This is an excellent Lead-level scenario.
37. Azure DevOps + Application Insights
You can connect deployment and monitoring:
Azure DevOps
|
v
Deploy
|
v
App Service
|
v
Application Insights
|
v
Azure Monitor
Suppose deployment happens:
Version 1.2.0
Then Application Insights shows:
Error rate
↑
Latency
↑
The Lead can investigate whether the new release caused the regression.
38. Production Deployment Strategy
I would recommend:
Developer
|
v
Feature Branch
|
v
Pull Request
|
+-- Reviewer Approval
+-- Build Validation
+-- Unit Tests
|
v
main
|
v
CI Pipeline
|
v
Artifact
|
v
DEV
|
v
Automated Tests
|
v
QA
|
v
UAT
|
v
Production Approval
|
v
PROD
|
v
Application Insights
39. Important Lead-Level Principle
Build Once, Deploy Many
Don't do:
Build → DEV
Build → QA
Build → PROD
Instead:
Build
|
v
Artifact
|
+---- DEV
|
+---- QA
|
+---- PROD
The same artifact should progress through environments.
This reduces "works in QA but not in production" problems caused by different builds.
40. Another Important Principle — Shift Left
Testing shouldn't start only in production.
You want:
Developer
↓
Compile
↓
Unit Test
↓
Static Analysis
↓
Security Scan
↓
Integration Test
↓
Deploy
The earlier you detect a defect, the cheaper it is to fix.
41. Rollback
Suppose:
Version 2.0
is deployed and causes:
HTTP 500 ↑
Latency ↑
Exceptions ↑
A good pipeline should support rollback.
Conceptually:
Production
|
v
Version 2.0
|
X
Problem
|
v
Rollback
|
v
Version 1.9
But a mature deployment strategy also aims to make rollback safe with database migration compatibility and backward-compatible contracts.
42. Database Migration Problem
Suppose:
Application v2
requires:
NewColumn
You can't blindly rollback if the database migration has destroyed compatibility.
Use an approach such as:
Expand
↓
Deploy
↓
Migrate data
↓
Switch application
↓
Contract
This is an important Lead-level DevOps + architecture topic.
43. Azure DevOps vs GitHub Actions
You may be asked this.
Both support CI/CD.
Azure DevOps offers a broader suite:
Boards
Repos
Pipelines
Test Plans
Artifacts
GitHub combines source control, collaboration and Actions-based automation in a different platform model.
Lead answer:
"I don't choose solely based on tool popularity. I consider existing organizational tooling, source-control platform, enterprise governance, security, integrations, team expertise and deployment requirements."
44. Azure DevOps Interview Questions
Basic
What is Azure DevOps?
What is Azure Repos?
What is Azure Boards?
What is Azure Pipelines?
What is Azure Artifacts?
What is Azure Test Plans?
What is Git?
What is a Pull Request?
What is CI?
What is CD?
45. Intermediate Questions
Explain a CI/CD pipeline.
What is a build artifact?
What is a pipeline agent?
Microsoft-hosted vs self-hosted agent?
What are environments?
How do you configure DEV/QA/PROD?
How do you handle secrets?
What is a variable group?
What are service connections?
How do you implement approvals?
What are branch policies?
How do you implement rollback?
How do you deploy .NET applications?
How do you deploy Azure Functions?
How do you deploy Docker containers to AKS?
46. Lead-Level Questions
Q26. Design CI/CD for a microservices application.
You should draw:
Git
↓
PR
↓
Build
↓
Test
↓
Security
↓
Artifact
↓
ACR
↓
AKS
↓
Application Insights
Q27. How would you secure the pipeline?
Answer:
"I would use least-privilege service connections, managed identities where supported, Key Vault for secrets, branch protection, PR approvals, secret scanning, dependency and container scanning, environment approvals, audit logging and separation of duties."
Q28. How would you implement zero-downtime deployment?
Discuss:
Blue/Green
Canary
Rolling deployment
Health checks
Backward-compatible DB changes
Monitoring
Rollback
Q29. How would you handle a failed production deployment?
Strong answer:
Detect
↓
Stop further rollout
↓
Check Application Insights
↓
Compare deployment version
↓
Determine impact
↓
Rollback / forward fix
↓
Verify health
↓
Root Cause Analysis
↓
Improve pipeline
Q30. How would you design a pipeline for 20 microservices?
Don't necessarily create one giant pipeline.
Consider:
Shared Templates
|
+------------+------------+
| | |
v v v
Order Pipeline Payment Inventory
| Pipeline Pipeline
v v v
ACR ACR ACR
| | |
v v v
AKS AKS AKS
Use reusable YAML templates and standard pipeline conventions.
47. Real-Time .NET Lead Example
Let's put everything together.
Your company has:
Angular
ASP.NET Core
Azure SQL
Service Bus
Azure Functions
AKS
Key Vault
Application Insights
The delivery architecture:
Developer
|
v
Azure Repos
|
v
Pull Request
|
+--------+--------+
| |
v v
Review Build Validation
|
v
Azure Pipeline
|
+-------------------+-------------------+
| | |
v v v
Build Unit Test Security
| | |
+-------------------+-------------------+
|
v
Docker Build
|
v
Azure Container Registry
|
v
AKS
|
v
Application Insights
|
v
Azure Monitor
This is a very strong architecture to explain in a Lead interview.
48. What Would I Say in the Interview?
If asked:
"Explain how you have used Azure DevOps in your project."
You can answer:
"We used Azure Repos for Git-based source control and Azure Boards for Agile work management. Developers worked on feature branches and created pull requests with mandatory reviews and build validation. Azure Pipelines implemented CI/CD. The CI stage restored dependencies, built the .NET solution, executed unit tests and security/quality checks, and published an immutable artifact. Deployment stages promoted the same artifact through DEV, QA, UAT and Production with environment-specific configuration and approvals. Secrets were managed through Key Vault, and production deployments were monitored through Application Insights and Azure Monitor. For containerized services, the pipeline built Docker images, pushed them to Azure Container Registry and deployed them to AKS."
That's a strong .NET Lead-level answer.
49. One Diagram to Memorize
For your interview, remember this:
AZURE DEVOPS
|
+----------------------+----------------------+
| | |
v v v
BOARDS REPOS PIPELINES
| | |
Stories Git Build
Tasks PR Test
Bugs Review Package
| | Deploy
+----------------------+----------------------+
|
v
Artifact
|
+-------------+-------------+
| | |
v v v
DEV QA PROD
|
v
Application Insights
|
v
Azure Monitor
The 10 things I recommend mastering for your Lead interview
Git + Branching Strategy
Pull Requests + Branch Policies
CI/CD
YAML Pipelines
Build Artifacts
Multi-stage deployment
Environment approvals
Key Vault + Secret Management
Docker + ACR + AKS deployment
Application Insights + Azure Monitor integration
