Module 1: Azure DevOps Platform Overview & Architecture

What is Azure DevOps?

Azure DevOps is Microsoft's integrated platform for the complete software delivery lifecycle. It provides everything a team needs to plan work, collaborate on code, build and test applications, and deploy to any cloud or on-premises environment — all from a single, unified platform.

Think of Azure DevOps as a Swiss Army knife for software teams — Boards is the project planner, Repos is the vault, Pipelines is the assembly line, Test Plans is quality control, and Artifacts is the warehouse. Each tool works independently, but they become significantly more powerful when used together. A work item in Boards can be linked to a commit in Repos, which triggers a build in Pipelines, runs tests via Test Plans, and publishes packages to Artifacts — all automatically traced and auditable.

A Brief History

Azure DevOps has deep roots in Microsoft's enterprise tooling history:

• 2005 — Team Foundation Server (TFS): Microsoft's first integrated ALM platform. On-premises only, tightly coupled to Visual Studio, used TFVC (Team Foundation Version Control)
• 2013 — Visual Studio Online: Cloud-hosted version of TFS, later renamed Visual Studio Team Services (VSTS)
• 2018 — Azure DevOps: Complete rebrand and modernization. Services split into independently adoptable components. Git became the default. REST APIs opened the platform to any language and tool
• Today: Used by 80,000+ organizations, processing millions of CI/CD pipelines daily

Two Deployment Models

Azure DevOps offers two deployment options to accommodate different organizational requirements:

The Five Integrated Services

Azure DevOps is composed of five core services. Each service can be enabled or disabled independently per project — you only use what you need. Many organizations start with Pipelines + Repos and add Boards later, or use Boards + Repos while keeping CI/CD in another tool. This modularity is a key differentiator.

                                flowchart TD
                                    B[Azure Boards] -->|Work items link to| R[Azure Repos]
                                    R -->|Commits trigger| P[Azure Pipelines]
                                    P -->|Runs| T[Azure Test Plans]
                                    P -->|Publishes to| A[Azure Artifacts]
                                    A -->|Consumed by| P
                                    T -->|Reports on| B
                                    B -->|Tracks releases from| P
                            

Azure Boards — Agile Work Tracking

Azure Boards provides rich, customizable work tracking with native support for Scrum, Kanban, and CMMI process templates. Work items follow a hierarchy: Epics → Features → User Stories/PBIs → Tasks. Teams get interactive Kanban boards, sprint backlogs, burndown charts, and dashboards — all without any third-party tools.

• Customizable work item types and fields
• Sprint planning with capacity tracking
• Kanban boards with WIP limits and swimlanes
• Queries and dashboards for reporting
• Integration with GitHub commits and PRs

Azure Repos — Git Repositories

Azure Repos provides unlimited private Git repositories with enterprise-grade branch policies. Pull requests support required reviewers, build validation, linked work items, and comment resolution — ensuring code quality before merge.

• Unlimited private Git repos (also supports legacy TFVC)
• Branch policies: required reviewers, build validation, linked work items
• Pull request workflows with threaded comments
• Semantic code search across all repos
• Large file support (Git LFS built-in)

Azure Pipelines — CI/CD Automation

Azure Pipelines is a cloud-hosted CI/CD service that builds, tests, and deploys code to any platform. It supports YAML-defined pipelines (infrastructure as code) and classic visual editor pipelines. With 1,800 free minutes/month for cloud-hosted agents and unlimited minutes for self-hosted agents, it scales from side projects to enterprise workloads.

• YAML pipelines (versioned with code) and classic editor (visual)
• Multi-stage pipelines with approvals and gates
• Support for any language: .NET, Java, Node.js, Python, Go, Rust, etc.
• Deploy to any cloud: Azure, AWS, GCP, on-premises
• Environments with deployment history and health checks

Azure Test Plans — Test Management

Azure Test Plans provides manual and exploratory testing tools integrated with your development workflow. Test cases link directly to user stories, test runs generate bugs with reproduction steps, and results feed into release quality gates.

• Manual test case management with shared steps
• Exploratory testing with browser extension
• Test suites linked to requirements and sprints
• Automated test result tracking from pipelines
• Requires Basic + Test Plans access level (paid add-on)

Azure Artifacts — Package Management

Azure Artifacts hosts your private package feeds for NuGet, npm, Maven, Python (PyPI), and Universal Packages. It acts as a caching proxy for public registries (npmjs.com, nuget.org) and provides upstream sources to combine internal and external packages in a single feed.

• Support for NuGet, npm, Maven, Python, Universal Packages
• Upstream sources (proxy public registries through your feed)
• Immutable package versions with retention policies
• Feed-level permissions and scoped access
• 2 GB free storage per organization

When to Choose Azure DevOps vs GitHub

Since Microsoft owns both Azure DevOps and GitHub, teams often ask: "Which should we use?" The answer depends on your team's priorities, existing ecosystem, and governance requirements. Here's a detailed comparison across key dimensions:

When Azure DevOps Wins

• Enterprise governance — Complex permission hierarchies, audit requirements, compliance
• Agile project management — Teams need full-featured boards with capacity planning, burn-down charts, and custom processes
• TFVC legacy — Large teams still using centralized version control for massive monorepos
• Regulated industries — Healthcare, finance, government with strict data residency or on-premises requirements
• Integrated test management — QA teams needing manual test plans linked to requirements
• Mixed ecosystems — Teams deploying to multiple clouds (Azure, AWS, GCP) with complex pipelines

When GitHub Wins

• Open source — Community collaboration, public repos, contributor workflows
• Developer experience — Simpler UX, faster onboarding, AI-native (Copilot)
• Actions marketplace — 20,000+ community actions for any integration
• Inner source — Organizations wanting open-source-style collaboration internally
• Security scanning — Native Dependabot, CodeQL, secret scanning

For CI/CD concepts that apply to both platforms, see Part 14: Continuous Integration.

Organization, Project & Team Hierarchy

Azure DevOps organizes work in a three-level hierarchy. Understanding this structure is critical — it determines how permissions flow, where resources live, and how teams collaborate. Think of it like a company structure: the Organization is the company, Projects are departments, and Teams are the working groups within each department.

                                flowchart TD
                                    O[Organization
dev.azure.com/contoso] --> P1[Project: WebApp]
                                    O --> P2[Project: MobileApp]
                                    O --> P3[Project: DataPlatform]
                                    P1 --> T1[Team: Frontend]
                                    P1 --> T2[Team: Backend]
                                    P1 --> T3[Team: DevOps]
                                    T1 --> R1[Repos]
                                    T1 --> B1[Board View]
                                    T2 --> R2[Repos]
                                    T2 --> B2[Board View]
                                    T3 --> PL[Pipelines]
                                    T3 --> B3[Board View]
                            

Organization Level

The Organization is the top-level container. It maps to your company or business unit. All billing, user management, and global policies live here. Your organization URL is https://dev.azure.com/{organization-name}.

Project Level

A Project is a boundary for related work. It contains repos, pipelines, boards, and test plans. Projects have their own security groups and can be public (visible to everyone) or private (members only). Most organizations have 3–15 projects, organized by product, business unit, or domain.

Team Level

A Team is a group of people working together within a project. Each team gets its own board view, backlog, sprint iterations, and capacity settings. The default team shares the project name, but you can create multiple teams — e.g., "Frontend," "Backend," "QA" — each with their own sprint cadence and work view.

Best Practices: Mono-Project vs Multi-Project

The following Azure CLI commands demonstrate how to create the organizational hierarchy programmatically. You'll need the Azure DevOps CLI extension installed.

# ============================================================
# Azure DevOps CLI: Creating Organization Hierarchy
# Prerequisites: Azure CLI + DevOps extension
# Install: az extension add --name azure-devops
# ============================================================

# Step 1: Configure the default organization
# This saves you from passing --org on every command
az devops configure --defaults organization=https://dev.azure.com/contoso

# Step 2: Create a new project
# --process: Scrum, Agile, CMMI, or Basic
# --source-control: git (default) or tfvc
# --visibility: private (default) or public
az devops project create \
    --name "WebApp" \
    --description "Customer-facing web application and APIs" \
    --process "Scrum" \
    --source-control git \
    --visibility private

# Step 3: Set the project as default for subsequent commands
az devops configure --defaults project=WebApp

# Step 4: Create teams within the project
# Teams get their own board view, backlog, and sprint settings
# Note: --project is required even after setting defaults (CLI quirk)
az devops team create --name "Frontend" --description "React/Next.js frontend team" --project WebApp
az devops team create --name "Backend" --description "API and microservices team" --project WebApp
az devops team create --name "Platform" --description "DevOps, infra, and SRE" --project WebApp

# Step 5: List all teams to verify
az devops team list --project WebApp --output table

Users, Access Levels & Security Model

Azure DevOps uses a layered security model combining access levels (what features a user can see) with security groups (what actions they can perform). This dual model lets you grant a stakeholder read-only access to boards without seeing repos, or give a contractor contributor access to one specific repo but nothing else.

Access Levels

Access levels control which features of the Azure DevOps web portal a user can access. They're assigned per-user and determine the ceiling of what's available — security groups then refine within that ceiling.

Security Groups

Within each access level, security groups control granular permissions. Azure DevOps creates default groups at each level of the hierarchy:

• Project Administrators — Full control over project settings, repos, pipelines, and user management
• Contributors — Create/edit code, work items, pipelines. Cannot change project settings.
• Readers — View-only access to all project resources
• Build Administrators — Manage build pipelines, agent pools, and build permissions
• Release Administrators — Manage release pipelines and deployment environments

Service Principals & Managed Identities

For automation (pipeline service connections, API integrations), Azure DevOps supports service principals and managed identities instead of personal access tokens. This eliminates the risk of tokens expiring or being tied to a user who leaves the organization. We'll cover this in depth in Module 10: Security & Compliance.

The following commands demonstrate managing users and access levels via the CLI:

# ============================================================
# Managing Users and Access Levels via Azure CLI
# These commands manage who can access your organization
# ============================================================

# Add a user to the organization with Basic access
# --email-id: The user's Microsoft account or Entra ID email
# --license-type: stakeholder, express (Basic), advanced, or earlyAdopter
az devops user add \
    --email-id "jane.smith@contoso.com" \
    --license-type express \
    --org https://dev.azure.com/contoso

# Add a stakeholder (free — great for PMs, designers, executives)
az devops user add \
    --email-id "pm-lead@contoso.com" \
    --license-type stakeholder \
    --org https://dev.azure.com/contoso

# List all users and their access levels
az devops user list --org https://dev.azure.com/contoso --output table

# Update a user's access level (e.g., promote from stakeholder to basic)
az devops user update \
    --user "jane.smith@contoso.com" \
    --license-type express \
    --org https://dev.azure.com/contoso

# Add a user to a specific security group within a project
# First, list available groups:
az devops security group list \
    --project WebApp \
    --output table

# Then add the user as a member (use group descriptor from above)
az devops security group membership add \
    --group-id "vssgp.PROJECT_CONTRIBUTORS_DESCRIPTOR" \
    --member-id "jane.smith@contoso.com"

Getting Started: Your First Project

Let's walk through creating your first Azure DevOps organization and project from scratch. This takes about 5 minutes and requires only a Microsoft account (personal or work/school).

Step 1: Create an Organization

1. Navigate to https://dev.azure.com
2. Sign in with your Microsoft account
3. Click "Create new organization"
4. Choose a name (this becomes your URL: dev.azure.com/your-name)
5. Select a region for your data (choose the closest geographic region)

Step 2: Create Your First Project

The following script automates project creation with recommended default settings. It also initializes the repository with a README and .gitignore file:

# ============================================================
# Complete First-Project Setup Script
# Run these commands after creating your organization
# ============================================================

# Install the Azure DevOps CLI extension (one-time setup)
az extension add --name azure-devops

# Authenticate (opens browser for interactive login)
# Use --tenant if your account belongs to multiple Entra ID tenants
az login --tenant YOUR_TENANT_ID

# Set your organization as the default
# Replace 'your-org' with your actual organization name
az devops configure --defaults organization=https://dev.azure.com/your-org

# Create a project with Scrum process template
# Scrum is recommended for teams new to Azure DevOps
az devops project create \
    --name "MyFirstProject" \
    --description "Learning Azure DevOps with hands-on exercises" \
    --process "Scrum" \
    --source-control git \
    --visibility private

# Set the new project as default
az devops configure --defaults project=MyFirstProject

# Verify project was created successfully
az devops project show --project MyFirstProject --output table

# Initialize the default repository with a README
# First, get the repo ID
az repos list --output table

# Clone the repo locally (replace URL with your actual repo URL)
git clone https://dev.azure.com/your-org/MyFirstProject/_git/MyFirstProject

# Create initial files
cd MyFirstProject
echo "# MyFirstProject" > README.md
echo "Learning Azure DevOps — CI/CD, Boards, and more." >> README.md
git add .
git commit -m "Initial commit: Add README"
git push origin main

Step 3: Configure Branch Policies

Branch policies prevent direct pushes to protected branches, ensuring all changes go through pull requests with proper review. This is a fundamental best practice for any team.

# ============================================================
# Configure Branch Policies for the main branch
# These enforce code review before any merge to main
# ============================================================

# Get the repository ID (needed for policy commands)
REPO_ID=$(az repos list --query "[0].id" --output tsv)

# Require at least 1 reviewer for pull requests to main
az repos policy approver-count create \
    --branch main \
    --repository-id $REPO_ID \
    --enabled true \
    --minimum-approver-count 1 \
    --creator-vote-counts false \
    --allow-downvotes false \
    --reset-on-source-push true \
    --blocking true

# Require linked work items on pull requests
# This ensures every change is traceable to a requirement
az repos policy work-item-linking create \
    --branch main \
    --repository-id $REPO_ID \
    --enabled true \
    --blocking true

# Require a successful build before merge
# (Configure this after creating your first pipeline in Module 3)
# az repos policy build create \
#     --branch main \
#     --repository-id $REPO_ID \
#     --build-definition-id YOUR_PIPELINE_ID \
#     --enabled true \
#     --blocking true

For Git fundamentals including branching strategies and workflows, see Part 9: Git & Version Control.

Navigating the Azure DevOps Interface

The Azure DevOps web portal is organized around a consistent navigation pattern. Understanding the URL structure and navigation model helps you move efficiently — especially when managing multiple projects.

URL Structure

Every resource in Azure DevOps follows a predictable URL pattern. Once you learn it, you can navigate directly by editing the URL:

# ============================================================
# Azure DevOps URL Patterns
# These are the direct URLs for key resources
# ============================================================

# Organization home (lists all projects)
# https://dev.azure.com/{org}

# Project home (overview dashboard)
# https://dev.azure.com/{org}/{project}

# Boards: Backlog view
# https://dev.azure.com/{org}/{project}/_backlogs/backlog

# Boards: Kanban board
# https://dev.azure.com/{org}/{project}/_boards/board

# Boards: Sprint view
# https://dev.azure.com/{org}/{project}/_sprints/taskboard

# Repos: File browser
# https://dev.azure.com/{org}/{project}/_git/{repo}

# Repos: Pull requests
# https://dev.azure.com/{org}/{project}/_git/{repo}/pullrequests

# Pipelines: All pipelines
# https://dev.azure.com/{org}/{project}/_build

# Pipelines: Specific run
# https://dev.azure.com/{org}/{project}/_build/results?buildId={id}

# Artifacts: Package feeds
# https://dev.azure.com/{org}/{project}/_artifacts

# Project settings
# https://dev.azure.com/{org}/{project}/_settings

Web Portal Structure

• Top bar — Organization switcher, project selector, search, user settings
• Left sidebar — Service navigation (Overview, Boards, Repos, Pipelines, Test Plans, Artifacts)
• Breadcrumbs — Show your current location within the hierarchy
• Settings gear (⚙️) — Context-sensitive settings for the current service/project
• Notifications bell (🔔) — Alerts for assigned work items, PR reviews, pipeline failures

REST API Overview

Azure DevOps exposes a comprehensive REST API for every operation available in the UI. This enables automation, custom integrations, and programmatic management. The API follows OData conventions with versioning:

# ============================================================
# Azure DevOps REST API Quick Examples
# Base URL: https://dev.azure.com/{org}/{project}/_apis
# Authentication: Personal Access Token (PAT) as Basic Auth
# ============================================================

# List all projects in an organization
# -u :{PAT} uses empty username with PAT as password
curl -s -u ":YOUR_PAT_TOKEN" \
    "https://dev.azure.com/contoso/_apis/projects?api-version=7.1" \
    | jq '.value[].name'

# Get details of a specific work item
curl -s -u ":YOUR_PAT_TOKEN" \
    "https://dev.azure.com/contoso/WebApp/_apis/wit/workitems/42?api-version=7.1" \
    | jq '{id: .id, title: .fields."System.Title", state: .fields."System.State"}'

# List repositories in a project
curl -s -u ":YOUR_PAT_TOKEN" \
    "https://dev.azure.com/contoso/WebApp/_apis/git/repositories?api-version=7.1" \
    | jq '.value[] | {name: .name, defaultBranch: .defaultBranch}'

# Trigger a pipeline run via API
curl -s -X POST -u ":YOUR_PAT_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{"resources": {"repositories": {"self": {"refName": "refs/heads/main"}}}}' \
    "https://dev.azure.com/contoso/WebApp/_apis/pipelines/1/runs?api-version=7.1"

Key Integrations & Extensions

Azure DevOps is designed as an open platform that integrates with hundreds of tools across the development ecosystem. Its extension model lets you add capabilities without waiting for Microsoft to build them.

Microsoft Ecosystem Integration

• Microsoft Azure — Deploy directly to App Service, AKS, Functions, VMs with native service connections
• Microsoft Teams — Get pipeline notifications, create work items, and approve deployments without leaving Teams
• Power BI — Connect to the Analytics OData feed for advanced reporting and custom dashboards
• Visual Studio / VS Code — Native extensions for work item tracking, PR reviews, and pipeline monitoring
• Microsoft Entra ID — Single sign-on, conditional access policies, and group-based licensing

Third-Party Integrations

• Slack — Pipeline notifications, work item updates, and slash commands for creating items
• ServiceNow — Change management approvals as pipeline gates, ITSM integration
• Jira — Bidirectional sync of work items for organizations migrating or using both tools
• SonarCloud/SonarQube — Code quality and security analysis as pipeline tasks
• Terraform/Pulumi — Infrastructure as Code deployment tasks built into pipelines
• Docker/Kubernetes — Container build, push, and deployment tasks

Extensions Marketplace

The Azure DevOps Marketplace hosts 1,000+ extensions created by Microsoft and the community. Extensions can add new pipeline tasks, board widgets, dashboard components, and entirely new hub pages.

Webhooks & Service Hooks

Azure DevOps can push real-time event notifications to any HTTP endpoint via Service Hooks. This enables custom integrations without polling the API:

{
    "publisherId": "tfs",
    "eventType": "build.complete",
    "resource": {
        "id": 12345,
        "buildNumber": "20260603.1",
        "status": "succeeded",
        "result": "succeeded",
        "project": {
            "name": "WebApp"
        },
        "definition": {
            "name": "CI-Pipeline"
        },
        "requestedFor": {
            "displayName": "Jane Smith"
        },
        "finishTime": "2026-06-03T14:30:00Z"
    },
    "createdDate": "2026-06-03T14:30:01Z"
}

Service hooks support 20+ event types including work item updates, code pushes, pull request changes, build completions, and release deployments. You configure them in Project Settings → Service hooks.

Exercises