What is Azure DevOps?

A unified platform by Microsoft that brings together tools for planning, developing, delivering, and operating software at scale.

🧒 Simple Explanation (ELI5)

Imagine you're building a house. You don't just show up with a hammer — you need a blueprint (what to build), a lumber yard (where materials are stored), a construction crew (who follows the plan step by step), a warehouse (where finished parts are kept until needed), and an inspector (who verifies everything is safe before anyone moves in).

Azure DevOps is all five of those things in one place:

• Azure Boards = the blueprint — you write down tasks, assign them, and track who's doing what
• Azure Repos = the lumber yard — all your code (material) is stored here, versioned, and protected
• Azure Pipelines = the construction crew — they automatically build, test, and deploy your code every time you make a change
• Azure Artifacts = the warehouse — finished packages (NuGet, npm, Maven, Python) are stored here so everyone can use them
• Azure Test Plans = the inspector — manual and automated testing to make sure everything works before it goes live

Without Azure DevOps? You'd need a separate tool for each job — Jira for tasks, GitHub for code, Jenkins for builds, Nexus for packages, and a spreadsheet for test cases. That's five logins, five dashboards, five sets of permissions, and zero integration between them. Azure DevOps puts it all under one roof with a single identity, single permissions model, and native integration between every service.

🔧 Technical Explanation

The Five Core Services

Azure DevOps is a suite of five integrated services offered as a cloud-hosted SaaS platform (dev.azure.com) or as a self-hosted server product (Azure DevOps Server, formerly TFS). Each service can be used independently or together.

1. Azure Boards

A work-tracking system that supports Agile, Scrum, and CMMI process templates out of the box. It provides:

• Work Items: Epics → Features → User Stories → Tasks (hierarchical). Each work item has fields for description, acceptance criteria, effort, priority, and custom fields.
• Boards (Kanban): Visual cards on columns (New → Active → Resolved → Closed). Drag-and-drop, WIP limits, swimlanes, and board-level rules.
• Sprints (Scrum): Sprint planning with backlog, capacity tracking, burndown charts, and velocity metrics.
• Queries & Dashboards: Custom queries to filter work items, plus configurable dashboards with widgets for charts, burndowns, and team velocity.
• GitHub Integration: Link work items to GitHub commits and PRs using AB#1234 syntax in commit messages.

2. Azure Repos

Enterprise-grade Git repositories with full support for branching, pull requests, and code review. Key features:

• Unlimited free private repos — no per-repo pricing. Each project can have multiple repositories.
• Branch Policies: Require PR reviews, linked work items, successful builds, comment resolution, and merge strategies (squash, rebase, merge commit).
• Code Search: Semantic search across all repos in your organization — find code, classes, or methods instantly.
• TFVC support: Also supports Team Foundation Version Control (centralized) for legacy codebases, though Git is recommended for all new projects.

3. Azure Pipelines

The CI/CD engine — arguably the most powerful service in the suite. It supports building, testing, and deploying code to any platform:

• YAML Pipelines: Pipelines defined as code in azure-pipelines.yml, version-controlled alongside your source. Supports stages, jobs, steps, templates, and conditional execution.
• Classic Pipelines: GUI-based drag-and-drop pipeline editor. Useful for teams not comfortable with YAML but being phased out in favor of YAML.
• Multi-platform: Runs on Microsoft-hosted agents (Windows, Ubuntu, macOS) or your own self-hosted agents (any OS, including containers).
• Environments & Approvals: Define deployment environments (dev, staging, production) with approval gates, checks, and deployment history.
• Service Connections: Securely connect to Azure subscriptions, Kubernetes clusters, Docker registries, AWS, GCP, and SSH endpoints.
• Free tier: 1 free Microsoft-hosted parallel job with 1,800 minutes/month. Self-hosted parallel jobs are unlimited for open-source and one free for private projects.

4. Azure Artifacts

A fully integrated package management solution supporting multiple feed types:

• NuGet (.NET), npm (JavaScript), Maven & Gradle (Java), Python (pip), and Universal Packages (any file type)
• Upstream sources: Proxy public registries (npmjs.org, nuget.org, PyPI) through your feed — packages are cached locally for reliability and speed.
• Feed views: Promote packages through quality levels: @local → @prerelease → @release. Consumers pull from the view they trust.
• Free tier: 2 GB of storage free per organization.

5. Azure Test Plans

A manual and exploratory testing tool designed for QA teams:

• Test Plans & Test Suites: Organize test cases into plans and suites, link them to user stories and builds.
• Manual Testing: Testers run step-by-step test cases using a web-based test runner or the Test & Feedback browser extension.
• Exploratory Testing: Ad-hoc testing with automatic screenshot capture, screen recording, and bug filing — evidence is attached to the work item automatically.
• Automated Test Results: Pipeline test results (JUnit, NUnit, xUnit) are displayed in Test Plans dashboards alongside manual results.

Organizations, Projects, and Teams

Azure DevOps uses a three-level hierarchy for organizing work:

Azure DevOps Cloud vs. Azure DevOps Server

Brief History & Evolution

Azure DevOps has gone through several name changes, but the DNA is the same:

Understanding this history matters because you'll encounter legacy terminology in the wild — "TFS," "VSTS," and "Release Management" are all predecessors of current Azure DevOps features. If a job posting says "TFS experience," they're talking about the same platform.

Azure DevOps REST API

Everything in Azure DevOps is accessible via a comprehensive REST API. This is critical for automation, custom integrations, and tooling:

# List all projects in your organization
curl -u :YOUR_PAT \
  "https://dev.azure.com/{org}/_apis/projects?api-version=7.1"

# Get all repositories in a project
curl -u :YOUR_PAT \
  "https://dev.azure.com/{org}/{project}/_apis/git/repositories?api-version=7.1"

# Queue a pipeline run
curl -X POST -u :YOUR_PAT \
  -H "Content-Type: application/json" \
  -d '{"definition":{"id":1}}' \
  "https://dev.azure.com/{org}/{project}/_apis/build/builds?api-version=7.1"

The API uses Personal Access Tokens (PATs) for authentication and follows the pattern: https://dev.azure.com/{org}/{project}/_apis/{area}/{resource}?api-version=7.1. There are also official client libraries for .NET, Python, Node.js, and Java.

📊 Azure DevOps Platform Overview

📊 Azure DevOps vs. GitHub vs. Jenkins vs. GitLab

Azure DevOps isn't the only DevOps platform, but it occupies a unique position — especially for Microsoft-ecosystem teams. Here's an honest comparison:

Azure DevOps vs GitHub Actions — Practical Decision Guide

The earlier comparison table is broad. For day-to-day engineering decisions, most teams are really choosing between Azure Pipelines and GitHub Actions. The best choice depends on whether your center of gravity is enterprise governance or GitHub-native developer workflow.

Choose Azure DevOps When

• You need Boards, Repos, Pipelines, and Artifacts under one governance model.
• You have strict approval, audit, and separation-of-duties requirements.
• Your delivery path is tightly coupled to Azure resources like ACR, AKS, and Key Vault.
• You are supporting legacy Classic pipelines while modernizing toward YAML.

Choose GitHub Actions When

• Your source of truth is already GitHub and you want CI/CD to live directly in the repo workflow.
• You want the broadest marketplace of reusable actions.
• Your team values lightweight developer ergonomics over deeper enterprise work-management features.
• You do not need Azure Boards or Azure DevOps-style release governance as the primary control plane.

Use Both When

• You keep source code in GitHub but still rely on Azure Boards for planning.
• You are gradually migrating pipelines from Azure DevOps to GitHub Actions or the reverse.
• Different business units have different operating models and forcing one tool would create more friction than value.

🛠️ Hands-on: Create Your First Organization, Project & Repo

Let's walk through setting up Azure DevOps from scratch — entirely through the web UI. You'll have a working org, project, and repo in under 10 minutes.

Prerequisites

• A Microsoft account (free — outlook.com, hotmail.com) or an Azure AD / Entra ID account (work/school)
• A modern web browser (Edge, Chrome, Firefox)

Step 1: Create an Organization

1. Navigate to https://dev.azure.com and sign in with your Microsoft account.
2. If this is your first time, you'll be prompted to create an organization. Choose a name (e.g., yourname-learning). This becomes your URL: dev.azure.com/yourname-learning.
3. Select your region — this determines where your data is stored. Choose the region closest to you. This cannot be changed later.
4. Click "Continue". Your organization is created.

Step 2: Create a Project

1. After creating the org, you're prompted to create your first project.
2. Enter a Project name: MyFirstProject
3. Set Visibility to Private (default — only invited users can see it).
4. Under Advanced, select:
   • Version control: Git (always choose Git for new projects)
   • Work item process: Agile (best for most teams; Scrum and CMMI are also available)
5. Click "Create project".

Step 3: Explore the Project

Once the project is created, you'll land on the project home page. Notice the left sidebar — it shows all five services:

📋 Overview         → Project summary, dashboards, wiki
📋 Boards           → Work items, sprints, backlogs
🔀 Repos            → Git repositories, branches, PRs
🚀 Pipelines        → CI/CD pipeline definitions and runs
📦 Artifacts        → Package feeds (NuGet, npm, etc.)
🧪 Test Plans       → Manual testing (requires Basic + Test Plans license)

Step 4: Create Your First Repository

1. Click Repos in the left sidebar. You'll see an empty default repo with the same name as your project.
2. Click "Initialize" to create the repo with a default README and .gitignore. Choose a template (e.g., VisualStudio) for the .gitignore.
3. The repo is created with an initial commit. You now have a working Git repository.

Step 5: Clone the Repo Locally

Click the "Clone" button in the top right of the Repos page. Copy the HTTPS URL:

# Clone using HTTPS (you'll be prompted for credentials)
git clone https://dev.azure.com/yourname-learning/MyFirstProject/_git/MyFirstProject

# Navigate into the repo
cd MyFirstProject

# Create a file, commit, and push
echo "Hello Azure DevOps" > hello.txt
git add hello.txt
git commit -m "feat: add hello world file"
git push origin main

Step 6: Verify in the Web UI

Go back to Repos → Files in the browser. You'll see your hello.txt file with the commit message. Click Commits to see the history. Click Branches to see the main branch. You've just completed the full loop: create org → create project → clone → push → verify.

Step 7: Create a Personal Access Token (PAT)

PATs are your programmatic password for Azure DevOps. You'll need one for Git credential authentication and API access:

1. Click your profile icon (top right) → Personal Access Tokens.
2. Click "+ New Token".
3. Configure the PAT:
   • Name: Git-access (descriptive name for what it's used for)
   • Organization: Select your org (or "All accessible organizations" for cross-org use)
   • Expiration: Choose a reasonable duration (30, 60, or 90 days). Avoid "custom" with 1-year expiry for security.
   • Scopes: Select only what you need. For basic Git access: Code → Read & Write. For pipeline automation: also add Build → Read & Execute.
4. Click Create. Copy the token immediately — it won't be shown again.

🐛 Debugging Scenarios

Scenario 1: "Cannot Create Project"

Symptom: You click "New Project" but get an error: "You do not have permission to create a project" or the button is grayed out.

Root Causes & Fixes:

• Insufficient permissions: Only users in the Project Collection Administrators group can create projects. Ask your org admin to add you, or go to Organization Settings → Permissions → Project Collection Administrators → Add.
• Organization policy: The org admin may have restricted project creation. Check Organization Settings → Policies → "Allow team and project administrators to invite new users" and related settings.
• Free tier limit: The free tier supports up to 5 users with Basic access. If you've hit the limit, you can't create projects that require additional licenses. Check Organization Settings → Billing.

# Check your access level:
# Organization Settings → Users → find your name → check "Access Level"
# Must be "Basic" or higher to create projects

# Check your group membership:
# Organization Settings → Permissions → Project Collection Administrators
# Your name must be listed (directly or through a group)

Scenario 2: "Pipeline Not Triggering"

Symptom: You push code but no pipeline runs. The Pipelines page shows no new runs.

Root Causes & Fixes:

• No trigger configured: YAML pipelines need an explicit trigger: section. If omitted, CI triggers are enabled for all branches by default — but if you added trigger: none, no automatic runs will happen.
• Pipeline is paused or disabled: Go to Pipelines → your pipeline → ⋯ (more options) → Settings. Check if it's disabled. Re-enable it.
• Branch filter mismatch: Your trigger might filter by branch name. If you push to feature/login but the trigger only watches main, it won't fire.
• New pipeline not yet created: Just having an azure-pipelines.yml in your repo isn't enough — you must create a pipeline definition in the Pipelines UI that points to it.

# Ensure your YAML has a proper trigger section:
trigger:
  branches:
    include:
      - main
      - feature/*
  paths:
    exclude:
      - '*.md'
      - docs/**

# If you want ALL branches to trigger:
trigger:
  - '*'

Scenario 3: "Cannot See Repos"

Symptom: You navigate to Repos in the sidebar, but it says "You don't have access" or the section is missing entirely.

Root Causes & Fixes:

• Repos service disabled: A project admin may have turned off the Repos service. Check Project Settings → General → Overview → Azure Repos. Toggle it on.
• Insufficient permissions: Your security group may not have Git repository read access. Check Project Settings → Repositories → Security. Ensure your group has at least Read permission.
• Stakeholder access level: Users with Stakeholder access cannot view or contribute to repos — they can only use Boards. You need at least Basic access. Check your access level in Organization Settings → Users.
• Private project + not a member: If the project is private and you haven't been explicitly added as a member, you won't see it at all. Ask a project admin to add you to the project via Project Settings → Teams or Permissions.

Scenario 4: "Clone Fails with 'Authentication Failed'"

Symptom: Running git clone https://dev.azure.com/... returns fatal: Authentication failed.

Root Causes & Fixes:

• Using your Microsoft password instead of a PAT: Azure DevOps HTTPS Git auth requires a Personal Access Token, not your login password. Generate a PAT from User Settings → Personal Access Tokens and use it as the password when prompted.
• PAT expired or revoked: Check your PAT list — if it shows expired, create a new one. PATs have an expiration date you set at creation time.
• PAT missing Code scope: If your PAT only has Work Items (Read) scope, it can't access repos. Create a new PAT with Code (Read & Write) scope at minimum.
• Credential Manager caching old credentials: On Windows, open Credential Manager → Windows Credentials and delete any entries for dev.azure.com or git:https://dev.azure.com. Try cloning again to be prompted for fresh credentials.

# On Windows — clear cached Git credentials
git credential-manager reject https://dev.azure.com

# On macOS — remove from Keychain
git credential-osxkeychain erase <<EOF
host=dev.azure.com
protocol=https
EOF

# Then re-clone — you'll be prompted for credentials
git clone https://dev.azure.com/{org}/{project}/_git/{repo}

🎯 Interview Questions

🌍 Real-World Use Case

Azure DevOps Pricing Quick Reference

Before diving into a real scenario, here's the pricing you'll need to justify Azure DevOps adoption:

For a team of 10 developers, the total cost is roughly $30/month (5 free Basic + 5 × $6). That's less than a single Jenkins server's compute cost on any cloud provider — and you get zero maintenance overhead.

E-Commerce Platform Migration to Azure DevOps

Consider a mid-size e-commerce company with 5 development teams (40 developers), using a mix of Jira, Bitbucket, Jenkins, and Nexus. Their pain points: tools are disconnected, developers context-switch between 5 dashboards, Jenkins maintenance consumes 20% of one engineer's time, and there's no unified audit trail for compliance.

What they adopted:

• Azure Boards replaced Jira — work items linked directly to commits and PRs with AB# syntax, giving full traceability from requirement to deployment.
• Azure Repos replaced Bitbucket — branch policies enforce 2 reviewers, linked work items, and passing CI on all protected branches. Code search across all 30+ repos from one search bar.
• Azure Pipelines replaced Jenkins — YAML templates standardized CI/CD across all teams. Docker builds went from 20 minutes (cold Jenkins agent) to 4 minutes (cached self-hosted agent). Environments with approvals replaced a manual Slack-based approval process.
• Azure Artifacts replaced Nexus — internal NuGet and npm packages published automatically from CI pipelines. Upstream sources proxy npmjs.org and nuget.org — builds don't break when public registries have outages.
• Azure Test Plans — QA team uses the Test & Feedback extension for exploratory testing. Screenshots and screen recordings attach to bugs automatically — developers get full reproduction context.

Results after 6 months:

• Deployment frequency: from bi-weekly to daily
• Lead time (commit to production): from 14 days to 2 hours
• Change failure rate: from 15% to 3%
• Mean time to recovery: from 4 hours to 15 minutes
• Tool maintenance overhead: eliminated (no more Jenkins server patching)
• Audit compliance: automated — every change traced from user story to production deployment

📝 Summary