End-to-end DevOps platform — Classic Editor, YAML Pipelines, User Management, Permissions, Artifacts, and production release patterns.
15
Chapters
30+
Pipelines
100%
Free
01🔵
Introduction to Azure DevOps
One Platform for Everything
Azure DevOps is like a Swiss Army knife for software teams — it has Git repos, project boards, CI/CD pipelines, artifact storage, and test management all in one place. Unlike Jenkins (which only does CI/CD), Azure DevOps handles the entire software lifecycle from planning to deployment.
The 5 Services — Think of Them as 5 Rooms
📂
Azure Repos
Your code lives here. Git repositories with pull requests, branch protection, and code review. Like GitHub but integrated into Azure DevOps.
📋
Azure Boards
Track work: user stories, bugs, tasks. Kanban boards, sprint planning, backlogs. Like Jira but built into the same platform.
⚙️
Azure Pipelines
Automate builds and deployments. Classic Editor (UI) or YAML (code). This is the CI/CD engine — the heart of DevOps.
📦
Azure Artifacts
Store private packages — NPM, Maven, NuGet, Python. Like a private Nexus or JFrog inside Azure DevOps.
🧪
Azure Test Plans
Manual and automated testing. Link test cases to user stories. Track test coverage.
Feature
Azure DevOps
GitHub Actions
Jenkins
Hosting
Cloud + On-prem (Server)
Cloud only
Self-hosted only
Pipeline
YAML + Classic UI
YAML only
Groovy (Jenkinsfile)
Project Boards
Built-in (Boards)
GitHub Issues
None (use Jira)
Artifact Registry
Built-in (Artifacts)
GitHub Packages
External (Nexus)
Best For
Enterprise + Azure + .NET
Open source + GitHub
Full control + plugins
02🏢
Organization & Project Setup
Structure Your Azure DevOps
Azure DevOps has a hierarchy: Organization → Project → Repos/Pipelines/Boards. Think of Organization as your company, Projects as departments, and Repos as individual applications.
Hierarchy Explained
🏢
Organization
Top level — your company name. Users, billing, and policies live here. URL: dev.azure.com/yourcompany
📂
Project
A workspace for a team or product. Has its own repos, boards, and pipelines. Example: "E-Commerce Platform" or "Mobile App"
📁
Repository
One Git repo inside a project. A project can have multiple repos. Example: order-service, user-service, frontend
Creating Your First Project
✓Go to dev.azure.com → Sign in with Microsoft account
✓Create Organization (your company name)
✓Click "New Project" → Name: "my-first-project"
✓Choose visibility: Private (default) or Public
✓Version Control: Git (always Git, never TFVC for new projects)
✓Work Item Process: Agile (recommended) or Scrum or Basic
✓Click Create → Your project is ready!
💡 Free Tier
Azure DevOps is FREE for up to 5 users with unlimited private repos and 1800 minutes/month of pipeline time. More than enough for small teams and learning.
03📂
Azure Repos & Branch Policies
Code Management Done Right
Azure Repos hosts your Git repositories. The killer feature is Branch Policies — rules that prevent bad code from reaching your main branch. No one can push directly to main. Every change must go through a pull request with reviews and passing builds.
Branch Policies — Non-Negotiable for Production
✓Require pull request to merge — NO direct push to main allowed
✓Minimum reviewers: 2 approvals required (at least 1 must be from code owners)
✓Build validation: CI pipeline MUST pass before merge is allowed
✓Linked work item: every PR must reference a user story or bug (traceability)
✓Comment resolution: ALL code review comments must be resolved
✓Reset votes on push: if developer pushes new commits, previous approvals are reset
✓Squash merge: clean single-commit history on main branch
Pull Request Workflow
WORKFLOW# 1. Developer creates feature branch
git checkout -b feature/payment-gateway
# 2. Developer makes changes and pushes
git add . && git commit -m "feat: add Razorpay integration"
git push origin feature/payment-gateway
# 3. Azure DevOps auto-creates Pull Request link
# 4. CI pipeline runs automatically on the PR
# 5. 2 reviewers review the code and approve
# 6. All checks pass → Merge button becomes available
# 7. Squash merge into main → clean history
# 8. Feature branch auto-deleted
04📋
Azure Boards
Track Work Like a Pro
Boards is the project management tool — think of it as Jira built into Azure DevOps. You create user stories, break them into tasks, track them on Kanban boards, and link them to commits and pull requests for full traceability.
Work Item Types
Type
Purpose
Example
Epic
Large business initiative (months)
Launch Payment Module
Feature
Deliverable functionality (weeks)
Razorpay Integration
User Story
User-facing requirement
As a user, I want to pay via UPI
Task
Technical work (hours/days)
Create Razorpay API wrapper
Bug
Defect to fix
Payment fails for amounts > 10000
💡 Auto-Linking
Include work item ID in commits or PR titles: "feat: add UPI flow #1234" — Azure DevOps automatically links the commit to work item #1234. In Boards, you can see which commits and PRs relate to each story. Full traceability from requirement to deployment.
05🖱️
Classic Editor Pipelines
UI-Based Build & Release — No YAML Needed
Classic Editor lets you build CI/CD pipelines by clicking buttons and filling forms in the web UI — no YAML knowledge needed. It is great for beginners and simple pipelines, but YAML is recommended for production because it is version-controlled.
Creating a Classic Build Pipeline
✓Go to Pipelines → New Pipeline → Click "Use the classic editor" link at bottom
✓Select source: Azure Repos Git → Pick your repository and branch
✓Choose template: ".NET Core" or "Maven" or "Node.js" or start with "Empty Job"
✓Agent Pool: Azure Pipelines (Microsoft-hosted) or your self-hosted pool
✓Add tasks by clicking the + button: Get Sources → Build → Test → Publish
✓Configure triggers: Enable "Continuous Integration" checkbox → builds on every push
✓Save & Queue → Your first build runs!
Classic vs YAML — Honest Comparison
Classic Editor
YAML Pipeline
Click buttons to configure
Write YAML code
Stored in Azure DevOps (not in Git!)
Stored in Git repo as azure-pipelines.yml
Cannot be code-reviewed in PR
Can be reviewed in pull requests
Easy to start, hard to maintain
Harder to start, easy to maintain
No version history
Full Git history for pipeline changes
Good for learning and demos
Required for production
Limited to available UI options
Full flexibility with scripts and conditions
Classic Release Pipeline (CD)
Classic Release pipelines are a separate concept — they take the output (artifact) from a Build pipeline and deploy it across environments. They have a visual stage editor that is very intuitive.
✓Go to Pipelines → Releases → New Release Pipeline
✓Select template: "Azure App Service deployment" or "Empty job"
✓Add Artifact: Select your Build pipeline as source
✓Configure Approvals: Click the lightning bolt icon → Add approvers for Staging and Production
✓Enable Continuous Deployment trigger: auto-deploys when new build artifact is ready
⚠️ Classic Releases are Legacy
Microsoft is pushing teams toward YAML-based multi-stage pipelines. Classic Releases still work and are supported, but new features are only added to YAML. Learn YAML for long-term career growth.
06📝
YAML Pipeline Basics
Pipeline as Code — The Modern Way
YAML pipelines live in your Git repository as a file called azure-pipelines.yml. Every change to the pipeline is tracked in Git, can be code-reviewed, and is fully reproducible. This is the recommended approach for all new projects.
Complete YAML Pipeline — Line by Line
AZURE-PIPELINES.YML# azure-pipelines.yml — stored in your Git repo root
trigger: # WHEN does it run?
branches:
include:
- main # Run on push to main
- release/* # Run on push to release branches
exclude:
- feature/experimental # Skip this branch
pool: # WHERE does it run?
vmImage: 'ubuntu-latest' # Microsoft-hosted Ubuntu agent
variables: # WHAT values do we need?
buildConfiguration: 'Release'
appName: 'order-service'
stages:
- stage: Build # STAGE 1: Build
displayName: 'Build & Test'
jobs:
- job: BuildJob
displayName: 'Build the application'
steps:
- script: echo "Building $(appName)" # Use variable with $()
displayName: 'Print app name'
- script: mvn clean package -DskipTests=false
displayName: 'Maven Build & Test'
- task: PublishBuildArtifacts@1 # Save output for deploy stage
inputs:
PathtoPublish: 'target/app.jar'
ArtifactName: 'drop'
- stage: Deploy # STAGE 2: Deploy
displayName: 'Deploy to Staging'
dependsOn: Build # Only runs if Build succeeds
jobs:
- deployment: DeployWeb # Special deployment job
environment: 'staging' # Links to environment (approvals here)
strategy:
runOnce:
deploy:
steps:
- download: current # Download artifact from Build stage
artifact: drop
- script: echo 'Deploying to staging...'
Pipeline Hierarchy — Simple
Level
Contains
Think of it as...
Pipeline
Stages
The whole recipe
Stage
Jobs
A chapter (Build, Test, Deploy)
Job
Steps
A section within the chapter
Step
Task or Script
One instruction (run this command)
07🚀
YAML Advanced Features
Variables, Conditions, Environments & Approvals
Master these features to build production-grade pipelines — variable groups linked to Key Vault, conditional stages, environment approvals, and deployment strategies.
Multi-stage YAML pipelines combine build AND deployment in one file. The artifact flows from Build → Staging → Production with approval gates between stages.
Templates let you write pipeline logic once and reuse it across all your microservices. Instead of copy-pasting the same Docker+K8s pipeline into 50 repos, you call a template. Change once, all 50 pipelines update.
YAML# extends wraps the ENTIRE pipeline — teams can only fill parameters
# They CANNOT skip security scans or remove approval gates
# azure-pipelines.yml (team's file — very simple)
resources:
repositories:
- repository: templates
type: git
name: DevOps/pipeline-templates
extends:
template: enterprise-pipeline.yml@templates
parameters:
appName: 'order-service'
buildTool: 'maven'
deployTo: 'aks-production'
💡 template vs extends
template inserts reusable steps — teams can add more. extends wraps the entire pipeline — teams ONLY fill in parameters, they cannot skip mandatory steps. Use extends when security scans and approvals are mandatory company-wide.
11📦
Azure Artifacts
Private Package Registry
Artifacts hosts private package feeds. Your CI pipeline publishes packages (NPM, Maven, NuGet), and other pipelines or developers consume them. Like having a private npm registry or Nexus inside Azure DevOps.
az artifacts feed create --name company-packagesCreate a new feed
az artifacts universal publish --feed company-packages --name mylib --version 1.0.0 --path ./distPublish a package
NPM Private Feed
YAML# .npmrc — point npm to your private feed
registry=https://pkgs.dev.azure.com/myorg/MyProject/_packaging/company-packages/npm/registry/
always-auth=true
# Pipeline step: publish to feed
- task: Npm@1
inputs:
command: 'publish'
publishRegistry: 'useFeed'
publishFeed: 'MyProject/company-packages'
12👥
User Management & Permissions
Control Access at Every Level
Azure DevOps has a layered permission system: Organization → Project → Repository → Pipeline → Environment. You can control who can see, edit, build, and deploy at every level. This is critical for enterprise security.
PERMISSIONS# For each Git repository, you can set:
# - Who can push to specific branches
# - Who can create branches
# - Who can force push (should be nobody!)
# - Who can bypass branch policies (emergency only)
# Example: Protect main branch
# Project Settings → Repos → Select repo → Security
# Deny: Force Push to main → Deny for ALL groups
# Allow: Contribute to main → Only via pull requests
# Allow: Bypass policies → Only "Emergency Admins" group
Personal Access Tokens (PATs)
PATs are like passwords for automation and CLI access. They have scoped permissions and expiration dates.
✓User Settings → Personal Access Tokens → New Token
✓Set scope: only grant minimum permissions needed (e.g., Code: Read)
✓Set expiration: 90 days max for security
✓Use PAT in Git clone: git clone https://pat@dev.azure.com/org/project/_git/repo
✓Use PAT in pipeline service connections for cross-project access
✓NEVER share PATs — each user should have their own
✓Rotate PATs every 90 days
Environment Approvals (Deployment Permissions)
🟢
Dev Environment
No approvals. Any contributor can trigger deploy.
🟡
Staging
1 approver from QA team. Branch filter: release/* only.
🔴
Production
2 approvers: tech lead + manager. Branch: main only. Business hours only. Exclusive lock (1 deploy at a time).
⚠️ Least Privilege
Give everyone the MINIMUM permissions they need. Developers don't need admin access. Interns should be Readers. Only the DevOps lead should be able to modify production environment approvals.
13🔗
Service Connections
Connect to External Services
Service connections authenticate your pipelines to external services — Azure subscriptions, Docker registries, Kubernetes clusters, AWS, SSH servers. They are centrally managed and scoped to specific pipelines.
Type
Connects To
Best Auth Method
Azure Resource Manager
Azure subscription
Managed Identity (no passwords!) or Service Principal
Docker Registry
ACR, Docker Hub, ECR
Service Principal for ACR, username/password for others
Kubernetes
AKS, EKS, GKE
Kubeconfig or Azure subscription (for AKS)
SSH
Remote Linux servers
SSH key pair
GitHub
GitHub repositories
GitHub App or PAT
Generic
Any REST API
Bearer token or basic auth
✓Create: Project Settings → Service Connections → New
✓Scope: Grant to specific pipelines only (not all pipelines)
✓Use Managed Identity when connecting to Azure resources (zero secrets to manage)
✓For production connections, require approval before use
✓Rotate Service Principal secrets every 90 days
✓Use Azure Key Vault for secrets instead of pipeline variables
14🏆
Best Practices
Enterprise Azure DevOps Patterns
Pipeline Best Practices
✓Use YAML pipelines for everything new — Classic only for legacy
✓Store azure-pipelines.yml in the same repo as your application code
✓Use templates for shared build/deploy logic across microservices
✓Use extends templates for mandatory security scans and approvals
✓Variable groups linked to Azure Key Vault for secrets (auto-rotation)
✓Multi-stage pipelines: Build → Test → Staging → Production in one file
✓Environment approvals with branch filters and deployment windows
✓Self-hosted agents for private network access and faster builds
Security Best Practices
✓Connect Azure Active Directory for SSO and MFA
✓Branch policies on main: require PR, reviewers, passing build
✓Folder-level service connections (team isolation)
✓PATs with minimum scope and 90-day expiration
✓Managed Identity for Azure connections (no passwords to rotate)
✓Audit logs: Organization Settings → Auditing → review who changed what
✓Never store secrets in pipeline variables — use Key Vault
✓Restrict who can modify production environment approvals
15💼
Interview Questions
30+ Azure DevOps Q&A
Platform & Basics
❓
What is Azure DevOps?
All-in-one DevOps platform by Microsoft: Repos (Git), Boards (Agile), Pipelines (CI/CD), Artifacts (packages), Test Plans. Available as cloud service or on-premises (Azure DevOps Server).
❓
Classic vs YAML pipeline?
Classic: UI-based, not in Git, easy to start. YAML: code-based, version-controlled, reviewable in PRs, recommended for production. Classic Releases are legacy; YAML multi-stage is the future.
❓
What are Branch Policies?
Rules on branches: require PR (no direct push), minimum reviewers, build validation (CI must pass), linked work items, comment resolution. Enforce code quality automatically.
❓
Organization vs Project?
Organization = company level (users, billing, policies). Project = team/product level (repos, boards, pipelines). One org has many projects.
Pipelines & Deployment
❓
What is a deployment job?
Special job type with environment, strategy, and lifecycle hooks. Uses deployment: instead of job:. Supports approvals, deployment history, and rollback tracking.
❓
How do approvals work?
Configured on Environments (not pipelines). When pipeline targets environment \"production\", configured approvers must approve. Pipeline pauses until approval.
❓
What are Variable Groups?
Shared variable collections usable across multiple pipelines. Can be linked to Azure Key Vault for automatic secret rotation. Created in Library section.
❓
template vs extends?
template inserts reusable steps (teams can add more). extends wraps entire pipeline (teams only fill parameters). extends enforces organizational standards — teams cannot bypass.
Security & Administration
❓
What are Service Connections?
Authenticated links to external services (Azure, K8s, Docker). Centrally managed, scoped to pipelines. Use Managed Identity for Azure to avoid password management.
❓
Self-hosted vs Microsoft-hosted agents?
Microsoft-hosted: managed VMs, fresh each build, no maintenance. Self-hosted: your VMs, access to private networks, persistent tools, faster (no VM spin-up).
❓
What are PATs?
Personal Access Tokens — scoped authentication tokens for CLI and API access. Each user creates their own. Set minimum permissions and 90-day expiration.
