Azure DevOps is a set of connected services that cover the whole life of a software change, from the first idea to the running product.

The problem it solves

Before tools like this became common, teams kept their task lists in spreadsheets, their code on a shared server, their test notes in documents and their release steps in a person’s head. Nobody could answer simple questions quickly. Which feature is this bug fix part of? Which build contains it? Who approved it for production? Every answer meant asking around, and every handover was a chance for something to be lost.

Azure DevOps removes that guesswork by keeping every step in one system and linking them together. A task can point to the code change that finished it, the code change can point to the build that tested it, and the build can point to the release that delivered it. This chain of links is called traceability, and it is one of the strongest reasons teams adopt the platform.

What DevOps itself means

DevOps is a way of working, not a product. It joins development (the people who write software) and operations (the people who run it) so they share goals, share tools and share responsibility. The aim is to release small changes often, with confidence, and to learn quickly from what happens in production. Azure DevOps is a toolbox that supports this way of working, but buying the toolbox does not automatically create the habits.

Cloud service and server edition

Azure DevOps comes in two forms. Azure DevOps Services is the hosted version that Microsoft runs for you, so there are no servers to patch and new features arrive continuously. Azure DevOps Server is the version you install and run on your own machines, which some organizations choose because of strict data-location or network rules. Most of the concepts in this tutorial apply to both, although the hosted version usually receives new capabilities first.

Before you use any feature, you need to understand the containers that hold everything.

The three layers

The top container is the organization. It represents your company or business unit, holds your users and billing, and is linked to your identity provider. Inside an organization you create projects. A project is a workspace for one product or one group of related work, and it holds its own boards, repositories, pipelines, test plans and package feeds. Inside a project you create teams, which are smaller groups of people who share a backlog, a sprint schedule and a dashboard.

flowchart TD
    ORG["Organization: company-wide container"] --> P1["Project A: Payments product"]
    ORG --> P2["Project B: Mobile app"]
    P1 --> T1["Team: Checkout"]
    P1 --> T2["Team: Billing"]
    P2 --> T3["Team: iOS"]
    P2 --> T4["Team: Android"]
        

How many projects should you have?

This is a question every growing company must answer, and there is a real trade-off. Many small projects give strong separation, because permissions, settings and history are isolated. However, work that crosses projects becomes harder to see, and sharing code or pipeline templates across projects takes extra effort. A single large project makes reporting and sharing easy, but one set of settings must serve everyone.

A common guideline is to start with fewer projects and split only when there is a clear reason, such as different security needs, different compliance rules or truly independent products. Teams, area paths and iteration paths already give you a lot of separation inside one project.

Identity and access

Azure DevOps Services connects to Microsoft Entra ID, the identity service that many companies already use for email and other tools. This means people sign in with their normal work accounts, and administrators can remove access in one place when someone leaves. Inside the platform, each person receives an access level that decides which services they can use, and permissions are granted through groups so that no one has to be configured one by one.

Azure DevOps is really five services sharing one login, one search and one set of links.

Use one, some or all

You do not have to adopt everything at once. Many teams keep their code on another platform and use only Pipelines. Others use Boards for planning and a different tool for builds. Each service works on its own, but the real power appears when they are combined, because the links between them create the traceability described in Chapter 1.

flowchart LR
    A["Boards: idea becomes a work item"] --> B["Repos: code change and pull request"]
    B --> C["Pipelines: build and automated tests"]
    C --> D["Test Plans: manual checks"]
    C --> E["Artifacts: packages published"]
    D --> F["Pipelines: release to production"]
    E --> F
    F --> G["Boards: work item closed with proof"]
        

Boards turns vague requests into small, trackable pieces of work that the whole team can see.

Work items

A work item is a single record of something that needs doing or fixing. It has a title, a description, an owner, a state such as New, Active or Done, and links to other items. Different types of work items exist for different purposes, and which types you see depends on the process you chose when the project was created.

Choosing a process

A process is a template that defines the work item types, states and rules. Azure DevOps offers four built-in choices, and each suits a different style of team.

Backlogs, boards and sprints

The backlog is an ordered list of everything the team might do. The top items are the most important and the most clearly described, and the bottom items are rough ideas. A sprint is a fixed period, often two weeks, in which the team commits to finish a selected slice of the backlog. During the sprint, the Kanban-style board shows each item as a card moving from left to right through columns such as To Do, Doing and Done.

Area paths and iteration paths

Two fields quietly control most of how Boards is organized. The area path says which part of the product or which team owns an item. The iteration path says which sprint the item belongs to. Teams are configured to watch specific area paths and iteration paths, which is how each team sees only its own backlog even though many teams share one project.

Repos stores your source code using Git, the most widely used version control system in the world.

What version control gives you

Version control keeps a complete history of every change to your files. You can see who changed a line, when, and why, and you can return to any earlier state if something breaks. Git is distributed, which means every developer holds a full copy of the history on their own machine and can work offline, then share changes later.

Branches

A branch is an independent line of work. A developer creates a branch for a feature or a bug fix, works there without disturbing anyone, and later merges the result into the main line. This keeps the main branch stable while experiments and unfinished work happen safely on the side.

Choosing a branching strategy

Teams follow different branching strategies, and the right one depends on how often they release.

gitGraph
    commit
    commit
    branch feature-login
    checkout feature-login
    commit
    commit
    checkout main
    commit
    merge feature-login
    commit
        

Linking code to work

Azure Repos lets a commit or pull request mention a work item by its number. The platform then creates a two-way link, so the work item shows which code changes completed it and the pull request shows which task it satisfies. This single habit is what makes the end-to-end tracking in Chapter 1 actually work.

A pull request is a formal request to merge a branch, and policies turn good habits into enforced rules.

The pull request

When a developer finishes a change, they open a pull request. It shows exactly what changed, lets teammates comment on individual lines, and records the discussion permanently. Reviewers can approve, request changes or ask questions. Only when the rules are satisfied can the change merge into the target branch.

Branch policies

Branch policies are settings on a protected branch, usually the main one, that every change must satisfy. Without them, anyone with permission could push directly and bypass review. With them, quality checks happen automatically and consistently, no matter who is in a hurry.

Merge styles

When a pull request completes, you can merge in different ways. A merge commit keeps the full branch history. A squash merge combines all branch commits into one tidy commit. A rebase replays the branch commits on top of the target for a straight, linear history. Squash merging is popular because the main branch reads like a clean list of completed changes.

Pipelines turns repeatable manual steps into an automatic process that runs the same way every time.

Continuous integration and continuous delivery

Continuous integration, often shortened to CI, means that every time someone pushes code, the system automatically builds it and runs tests. The goal is to find problems within minutes instead of weeks. Continuous delivery, or CD, extends this by automatically preparing and moving the tested build toward production, so that releasing becomes a routine event instead of a stressful one.

The building blocks

A pipeline is described in a file stored with your code, written in a format called YAML. Because it lives next to the code, it is versioned, reviewed and rolled back just like any other change. The file is organized into a few simple levels.

flowchart TD
    TR["Trigger: code pushed"] --> S1["Stage: Build"]
    S1 --> J1["Job: compile on an agent"]
    J1 --> ST1["Steps: restore, build, unit test"]
    ST1 --> S2["Stage: Deploy to Test"]
    S2 --> S3["Stage: Deploy to Production"]
        

YAML pipelines and classic pipelines

Azure Pipelines originally offered a visual designer, now called classic pipelines, where you built the process by clicking through a web editor. The modern and recommended approach is YAML pipelines, because they are stored as code, can be reviewed in pull requests, and can be reused through templates. New work should normally start with YAML, and classic pipelines are mostly kept alive for older projects.

A pipeline describes the work, but an agent is the machine that actually does it.

What an agent is

An agent is a computer, real or virtual, that runs the steps of a job. It receives instructions from Azure Pipelines, downloads your code, performs each step and reports results back. Agents are grouped into pools, and a job simply asks for a pool, then any free agent in that pool picks it up.

Microsoft-hosted and self-hosted agents

Microsoft-hosted agents are usually the best starting point. Teams move to self-hosted agents when builds must reach a private network, need unusual tools, or run so often that owning the machines becomes cheaper. There is also a managed middle option, where Microsoft operates agent pools inside your own Azure subscription so you gain control over size and network without managing the machines by hand.

Parallel jobs

The number of jobs that can run at the same moment is limited by your parallel job count. Organizations receive a small free allowance, and more capacity can be purchased. If you have two parallel jobs and five jobs waiting, three of them queue until a slot frees up. When builds feel slow, a long queue is often the real cause, not the build itself, so check the queue before blaming the code.

A mature pipeline builds once, then promotes the same output through every environment.

Build once, deploy many times

A key principle of reliable delivery is that you build your software a single time and then move that exact output through test, staging and production. If you rebuilt it for each environment, you could not be sure that what you tested is what you shipped. Azure Pipelines supports this by publishing the build output as a pipeline artifact that later stages download and deploy.

Deployment strategies

How you place a new version in front of users affects both risk and downtime. Azure Pipelines deployment jobs support several well-known strategies.

flowchart LR
    B["Build once and publish artifact"] --> D1["Deploy to Dev"]
    D1 --> D2["Deploy to Test"]
    D2 --> AP["Approval gate"]
    AP --> D3["Deploy to Staging"]
    D3 --> AP2["Approval and health checks"]
    AP2 --> D4["Deploy to Production"]
        

Templates for reuse

When many pipelines share the same steps, copying and pasting them creates a maintenance headache. Pipeline templates let you define a block of stages, jobs or steps once and reuse it everywhere, with parameters for the parts that differ. A central platform team can publish approved templates, so every product team gets secure and consistent building blocks without reinventing them.

Pipelines need to talk to outside systems and use sensitive values, and doing that safely is a skill of its own.

Service connections

A service connection is a stored, controlled link between Azure DevOps and an external system, such as an Azure subscription, a container registry, a Kubernetes cluster or another code host. Instead of scattering credentials through pipeline files, you define the connection once, and pipelines refer to it by name. Administrators decide which projects and pipelines may use each connection.

Safer sign-in with workload identity federation

Older service connections relied on long-lived secrets, which could expire unexpectedly or be stolen. The modern recommendation for connecting to Azure is workload identity federation. Here, Azure DevOps and Microsoft Entra ID establish trust, and the pipeline receives a short-lived token for each run instead of storing a password. There is no secret to rotate or leak, which removes a whole category of risk.

Variables and variable groups

Variables hold values that change between runs or environments, such as a server name or a feature setting. A variable group collects related variables in one library that many pipelines can share, so a change is made once. Variables can also be marked secret, which hides their values in logs and prevents them from being read back through the interface.

Azure Key Vault

For truly sensitive values such as passwords, certificates and API keys, the best practice is to store them in Azure Key Vault, a dedicated secure store. A variable group can be linked to a vault so that secrets are fetched at run time and never copied into Azure DevOps. Access is controlled, audited and easy to rotate in one place.

Speed is only valuable when it is paired with control, and environments are where control is applied.

What an environment is

An environment in Azure Pipelines represents a place where you deploy, such as Development, Staging or Production. It records the deployment history, so you can see which version is running where and who put it there. It can also be tied to specific resources such as a Kubernetes namespace or a group of virtual machines.

Approvals and checks

Approvals and checks are conditions attached to an environment. Before a deployment is allowed to begin, the pipeline pauses and waits until every condition is satisfied. This lets the production environment be strict while the development environment stays open and fast.

Protecting shared resources

The same idea extends beyond environments. Service connections, secure files, variable groups and agent pools can all require that a pipeline be explicitly authorized or approved before it uses them. This stops a brand-new, unreviewed pipeline from quietly reaching production credentials.

Modern software is built from reusable pieces, and Artifacts is the warehouse where those pieces are stored.

Why packages matter

Few applications are written entirely from scratch. They rely on libraries written by others, and companies also build their own shared libraries for logging, security or common business rules. A package is a bundled, versioned piece of software that can be downloaded and used by other projects. Without a managed place to keep packages, teams copy files between projects and lose track of which version is in use.

Feeds and supported formats

A feed is a container for packages with its own access rules. Azure Artifacts supports the common package types used across languages, including NuGet for .NET, npm for JavaScript, Maven and Gradle for Java, Python packages and a generic format called Universal Packages for any other files. This allows a single service to serve teams that use very different technologies.

Upstream sources

A feed can be connected to public registries, a feature called upstream sources. When someone requests a public package, the feed fetches it once and keeps a saved copy. This gives you two advantages. Builds keep working even if the public registry is down, and you retain the exact version you used, which protects you if a public package is later changed or removed.

Automated tests catch many problems, but human judgment still finds the ones nobody thought to automate.

Automated and manual testing together

Automated tests run inside pipelines and are ideal for checks that must repeat on every change, such as whether a calculation still gives the right answer. Manual testing is better for judging whether a screen feels confusing, for exploring unexpected paths, and for checking new features before automation exists. A healthy approach uses both, with automation as the wide base and manual testing used where people add the most value.

Test plans, suites and cases

Azure Test Plans organizes manual testing in three levels. A test plan covers a release or sprint. Inside it, test suites group related cases, often by feature or by requirement. A test case is a set of steps with an expected result. Testers run the cases, record pass or fail, attach screenshots and file bugs directly, and the bug stays linked to the failing test and the original requirement.

Quality gates in pipelines

Pipelines can publish test results and code coverage, which then appear in a build summary and on dashboards. Teams often turn important measures into gates, for example failing a build if tests fail or if coverage drops below an agreed level. Over time, the trend matters more than any single number, because a steadily falling trend warns that quality is eroding.

A delivery platform holds your source code and can push to production, which makes it a valuable target that deserves careful protection.

Access levels and permissions

Two ideas work together. An access level decides which services a person can use at all, for example Stakeholder for people who only view and comment on work, or Basic for full developers. Permissions then decide what that person can do inside each area, such as editing a pipeline or approving a pull request. Granting permissions through groups instead of individuals keeps the system understandable as the team grows.

Principle of least privilege

Give each person and each pipeline only the access needed for the job and nothing more. Build identities, for example, should be limited to the project they belong to, and read-only by default. When something does go wrong, whether through a mistake or an attack, the damage stays small because the identity involved could not reach very far.

Protecting the supply chain

Attackers increasingly target the build process itself, because compromising a pipeline can poison every product it creates. Good defenses include protected branches, required reviews, restricted use of service connections, trusted pipeline templates that cannot be bypassed, and scanning of dependencies and code for known weaknesses. Treat pipeline definitions as sensitive code, because whoever can change them can often change what reaches production.

What you cannot see, you cannot improve, so measurement is part of the platform’s purpose.

Dashboards and widgets

A dashboard is a page of widgets that show live information, such as the sprint burndown, recent build results, open bugs or the status of a release. Each team can have its own dashboard, and a shared one can show the health of the whole product. A good dashboard answers a few clear questions at a glance and is reviewed regularly in team meetings.

Analytics and reporting

Azure DevOps includes an analytics service that stores historical data about work items and pipelines. It powers built-in reports such as velocity, cumulative flow and cycle time, and it can feed external tools such as Power BI for custom reports. Historical data lets you answer questions like whether the team is getting faster and where work gets stuck.

Flow and delivery metrics

Four measures, often called the DORA metrics after the research group that popularized them, give a balanced picture of delivery health.

The first two measure speed, and the last two measure stability. Using all four together prevents a common trap, where a team speeds up by quietly sacrificing reliability. Healthy teams improve speed and stability at the same time.

Notifications and service hooks

Teams do not want to refresh a page waiting for news. Notifications send emails when a build fails or a pull request needs review. Service hooks go further by sending events to other tools, such as a chat application or an incident system, so the right people hear about important events where they already work.

Experienced teams repeat certain structures that work well and avoid certain traps that cause pain.

Patterns worth adopting

Traps to avoid

A short, practical checklist drawn from how successful teams use the platform every day.

Keeping builds fast

Slow pipelines drain a team’s energy. The best remedies are simple. Cache dependencies so they are not downloaded on every run. Split long test suites across parallel jobs. Run quick checks first, so a typo fails the build in seconds instead of after a long compile. Only run heavy tests on the stages where they matter, not on every tiny change.

Housekeeping

Every platform collects clutter over time. Set retention rules so old build records and artifacts are deleted automatically. Delete merged branches. Archive projects that are no longer active. A tidy platform is faster to search, cheaper to run and easier for new people to understand.

Three typical situations show how the pieces combine in practice.

A day in the life of one change

Follow a small change through the whole system to see the platform working together. It makes the earlier chapters feel connected.

sequenceDiagram
    participant PO as Product Owner
    participant Dev as Developer
    participant Repo as Azure Repos
    participant Pipe as Azure Pipelines
    participant Env as Production Environment
    PO->>Dev: Work item prioritized in Boards
    Dev->>Repo: Branch, commit and open pull request
    Repo->>Pipe: Build validation runs
    Pipe-->>Repo: Tests pass
    Repo->>Repo: Reviewers approve and merge
    Pipe->>Env: Deploy after approval and checks
    Env-->>PO: Feature live, work item closed
        

No, but they overlap. Both host Git repositories and run automated pipelines. Azure DevOps has stronger built-in planning and formal test management, while GitHub has a larger open-source community. They also work together, since Azure Boards and Azure Pipelines can connect to GitHub repositories.

No. Pipelines can build code from Azure Repos, GitHub, Bitbucket and other Git sources. Many teams use Pipelines alone as their automation engine.

Yes. Through service connections and extensions, pipelines can deploy to other clouds, to on-premises servers and to app stores. The platform is not tied to Azure.

Historically, a build pipeline created the output and a separate classic release pipeline deployed it. Modern YAML multi-stage pipelines combine both in one definition, with stages for build and deployment. New projects should prefer the multi-stage approach.

The most common reasons are that all parallel jobs are busy, no agent in the pool is free or matches the demands, or an approval or check is still pending. The run details page usually states which one applies.

Not necessarily, but consistency helps reporting. Within one project all teams share a process, so choose the one that fits most teams and use area paths and team settings for differences.

Prefer identity-based sign-in so that no secret exists. For remaining secrets, store them in Key Vault, mark pipeline variables as secret, restrict who can use service connections, and never place credentials in the repository.

No. Small teams use it too, often with just the free tier and a simple process. Its features scale from a handful of developers to thousands.

Create a project, add a repository, protect the main branch with a review requirement, and add a simple CI pipeline that builds and tests on every pull request. These four steps deliver a large share of the value.

Yes, the on-premises edition continues to receive updates for organizations that need to host their own tools. Check Microsoft’s current documentation for its support schedule and feature differences from the hosted service.

Azure DevOps brings planning, code, automation, testing and packages into one connected system. Boards decides what to build, Repos keeps the code safe and reviewed, Pipelines builds and delivers it, Test Plans checks it with human judgment, and Artifacts shares reusable parts. The real value lies in the links between them, because those links let you trace any change from idea to production, and prove that the right checks happened along the way. Success depends less on the tool and more on habits: small changes, fast feedback, strong protection for secrets and production, and honest measurement.