DevOps is a way of working, and Azure DevOps is a set of Microsoft tools that supports that way of working.

Let us start with the basic words. Software is the set of programs that run on computers and phones, such as a banking app or an online shop. A developer is a person who writes software. An operations team is the group that runs the software on servers and keeps it available to users. For many years these two groups worked separately. Developers finished a program and “threw it over the wall” to operations, who then struggled to run it. Misunderstandings, delays and blame were common.

DevOps, a joining of the words development and operations, is a culture and a set of practices in which both groups work together and share responsibility for the whole journey, from idea to running software. It stresses teamwork, small and frequent changes, automation of repetitive work, and learning from measurements.

Azure DevOps is Microsoft’s platform for supporting this journey. It offers tools for planning work, storing code, building and testing automatically, delivering software to servers, and sharing software packages. It comes in two forms: Azure DevOps Services, which runs in the Microsoft cloud, and Azure DevOps Server, which you install on your own computers if rules require it. This guide focuses on the cloud version.

Without good tools, software projects suffer from lost work, slow releases and surprise failures.

To appreciate Azure DevOps, picture a team that has no shared system. They keep their task list in a spreadsheet, send code to each other by email, build the program by hand on one person’s laptop, and copy files to the server late on Friday evening. What goes wrong?

Azure DevOps answers each problem: shared version control prevents lost work, automated builds make results consistent, pipelines make releases routine, boards give visibility, and automatic tests catch mistakes early.

Azure DevOps is made of five services that you can use together or separately.

flowchart LR
    B["Boards: plan the work"] --> R["Repos: write and review code"]
    R --> P["Pipelines: build, test, deploy"]
    P --> A["Artifacts: share packages"]
    P --> T["Test Plans: manual testing"]
    P --> U["Users get the new version"]
    U -. "feedback and new ideas" .-> B
        

You do not have to use all five. Many teams use Azure Pipelines with code stored in GitHub, or use Azure Boards only for planning. The services are designed to connect smoothly but can stand alone.

Azure DevOps is organized in layers, and understanding the layers helps you manage access and structure.

The top level is the organization, which represents your company or group and is the home for billing, users and settings. Inside an organization you create projects. A project is a container for one product or team’s work, and holds its own boards, repositories, pipelines, test plans and artifacts. You might create one project for your mobile app and another for your website.

Organizations connect to Microsoft Entra ID, the identity system used across Microsoft cloud services, so people sign in with their normal work accounts, and access can be removed centrally when someone leaves.

Azure Boards turns ideas and problems into trackable items that everyone can see.

Work in Azure Boards is recorded as work items. A work item is a small card describing one piece of work: its title, description, who is responsible, its state and how important it is. Different kinds of work items exist, and they fit together in layers.

Backlogs, boards and sprints

A backlog is an ordered list of work waiting to be done, with the most important items at the top. A Kanban board shows the same items as cards moving across columns, such as New, Active, Resolved and Done, so everyone can see progress at a glance. Many teams work in sprints, which are short fixed periods, often two weeks, in which the team commits to finish a chosen set of items. At the start, the team picks items from the backlog and plans the sprint; at the end, it reviews what was finished.

Good planning combines realistic commitments with visible progress.

Version control remembers every change to your code, so many people can work together safely.

Source code is the text files that programmers write. Version control is a system that records every change made to those files, who made it and why, so you can compare versions, go back to an earlier one and combine the work of many people. The most popular version control system is Git, and Azure Repos provides hosted Git repositories.

A branching plan keeps the main code stable while many people make changes.

Teams need an agreement about how branches are used. Without one, code becomes messy and hard to merge. Two common approaches exist.

To protect the main branch, Azure Repos offers branch policies, which are rules that every change must satisfy before it can be merged.

A pull request is the moment where teamwork, review and automation meet.

A pull request, often called a PR, is the standard way to propose a change. The author finishes work on a branch and opens a PR, which shows exactly what changed. Teammates read the changes, leave comments on specific lines, ask questions and suggest improvements. At the same time, automatic checks run in the background. When reviewers approve and the checks pass, the change is merged.

sequenceDiagram
    participant D as Developer
    participant R as Azure Repos
    participant P as Pipeline
    participant V as Reviewer
    D->>R: Push branch and open pull request
    R->>P: Trigger build validation
    P-->>R: Report build and test results
    R->>V: Request review
    V-->>R: Comment or approve
    D->>R: Update branch if needed
    R->>R: Policies satisfied: complete merge
    R->>P: Trigger main branch pipeline
        

Pipelines automate building, testing and delivering software every time code changes.

Two abbreviations appear everywhere in DevOps. CI stands for continuous integration. It means that every time someone changes the code, the system automatically builds the program and runs tests, so problems are found within minutes. CD stands for continuous delivery or continuous deployment. In continuous delivery, every successful build is automatically prepared and ready to release, and a human approves the final step. In continuous deployment, the release to users happens automatically with no manual approval at all.

A build turns source code into a runnable form. A test is an automatic check that the program behaves correctly. A deployment places the built program onto servers or services where users can use it. Azure Pipelines performs all of these steps according to instructions that you write down as a pipeline.

A pipeline is described in a text file stored with your code, so it can be reviewed and versioned.

Azure Pipelines lets you define a pipeline in a file written in a simple text format called YAML. The file lives in your repository next to the code. This idea is called pipeline as code. Because the pipeline is a file, changes to it go through pull requests, its history is recorded, and it can be copied to new projects easily. An older visual editor, called the classic editor, still exists, but YAML is the recommended path for new work.

A YAML pipeline has a clear set of nested building blocks.

An agent is a computer that actually carries out the steps of a pipeline.

A pipeline is only instructions. Something has to run them. That something is an agent, a machine with software that picks up jobs and runs them. Agents are grouped into pools. Azure Pipelines has two kinds of agents.

A release should climb through test environments, with safety checks before it reaches real users.

Releasing straight to production is risky. Mature teams promote the same built package through a series of environments, such as development, testing, staging and production. In Azure Pipelines, an environment is a named target that represents these places. It records deployments to it and can enforce approvals and checks before a deployment is allowed to proceed.

flowchart LR
    C["Code merged"] --> B["Build and unit tests"]
    B --> A["Artifact published"]
    A --> D1["Deploy to Dev"]
    D1 --> T["Automated tests"]
    T --> D2["Deploy to Staging"]
    D2 --> AP{"Manual approval"}
    AP -- Approved --> D3["Deploy to Production"]
    AP -- Rejected --> X["Stop and investigate"]
        

A key principle is build once, deploy many. The same tested package that went to staging is the one that goes to production, so you never rebuild and risk subtle differences. Only the settings, such as server names, change between environments.

Pipelines need permission to deploy, and that permission must be handled with great care.

To deploy to Azure, a pipeline must prove its identity. Azure DevOps stores this connection as a service connection, a saved and protected link to an external service such as an Azure subscription, a container registry or a code host. Pipelines use the connection by name without ever seeing the underlying secret in plain text.

Artifacts gives your team a private, trusted library for packages and shared code.

Modern software is built from many reusable pieces called packages, which are bundles of code shared as a single unit. Your team may create its own packages, for example a logging library used by five applications, and also rely on public packages from the internet. Azure Artifacts hosts package feeds, which are private shelves where packages are published, stored and downloaded.

Testing mixes fast automatic checks with careful human exploration.

Tests come in layers. The foundation is a large number of fast automatic tests, and on top are fewer, slower, more realistic ones.

Pipelines can run the automatic tests and publish the results and code coverage, which shows how much code the tests actually exercise. Azure Test Plans supports the human side. Testers write test cases, group them into plans and suites, run them step by step, record results and attach screenshots or bug reports. Exploratory testing tools let a tester record actions and file bugs linked directly to work items.

Pipelines can also build the servers and environments that your software runs on.

Infrastructure as code means describing servers, networks and cloud services in files instead of clicking through a portal by hand. Tools such as Bicep, Azure Resource Manager templates and Terraform read these files and create the matching resources. Because the files live in a repository, changes to infrastructure are reviewed and tracked just like application code, and environments can be recreated exactly.

Pipelines also work with containers, which are lightweight packages that contain a program together with everything it needs to run. A typical pipeline builds a container image, scans it, pushes it to a container registry, and deploys it to a service such as Azure Kubernetes Service or Azure Container Apps.

Security works best when it is built into every step instead of being added at the end.

DevSecOps adds security to the DevOps loop. Instead of a single security review before release, checks run automatically on every change, so problems are found early when they are cheap to fix.

DevOps improves what it measures, so choose a few meaningful numbers.

Teams often track four well-known measures, sometimes called the DORA metrics after the research program that studied them. They describe both speed and stability of delivery.

Azure DevOps helps with other signals too: pipeline success rates and durations, test pass rates, code coverage, open bug counts and sprint burndown. Dashboards display them, and analytics connect to Power BI for deeper reports. Release pipelines can also connect to Azure Monitor and Application Insights, so teams see how a new version behaves in production and can roll back quickly if needed.

Microsoft offers both Azure DevOps and GitHub, and many teams use them together.

GitHub, which is also owned by Microsoft, provides repositories, pull requests, issue tracking and its own automation called GitHub Actions. This leads to a common question: which one should we use? The answer depends on your team, and many organizations combine them. For example, code may live in GitHub while Azure Boards tracks work and Azure Pipelines builds and deploys.

Microsoft continues to evolve both products, with strong investment in GitHub. Before starting a large new initiative, check the current roadmap and guidance, and choose the tools that match your team’s habits, rules and existing investments.

Azure DevOps is billed mainly by users and by how much pipeline capacity you use.

Pricing for Azure DevOps Services follows a few simple ideas. A small number of users, usually the first five, can use the Basic features free of charge, and Stakeholders can always participate in a limited way at no cost. Additional Basic users are charged per month. Azure Test Plans is an add-on that is charged per user. For Azure Pipelines, you pay for parallel jobs, which determine how many pipeline jobs can run at the same time, and you may receive a free allowance. Azure Artifacts gives a free amount of storage, and charges for storage above it. Free allowances and prices change, and new organizations may need to request free parallel jobs, so always check the official pricing page.

Habits that experienced teams follow, and traps that beginners often fall into.

Seeing how organizations use Azure DevOps makes the ideas easier to remember.

No. Azure DevOps works with many languages, frameworks and clouds. You can build and deploy applications written in Java, Python, JavaScript, .NET and more, and deploy to other clouds or on-premises servers, although it integrates especially well with Azure.

No. The services work independently. Many teams use only Pipelines with code in GitHub, or only Boards for planning. Use the parts that solve your real problems.

Continuous integration automatically builds and tests every change soon after it is made. Continuous delivery automatically prepares every successful build for release, with a human approving the final step, and continuous deployment goes further by releasing automatically with no manual approval.

YAML pipelines are the recommended approach for new work because they live with your code, can be reviewed and versioned, and are easy to reuse with templates. The classic editor remains available for older pipelines.

Microsoft-hosted agents are maintained by Microsoft and give each job a clean machine. Self-hosted agents run on machines you control, which allows access to private networks and special tools, but you must maintain them.

Never put secrets in code or pipeline files. Use federated identity where possible so no long-lived secret exists, keep secrets in Azure Key Vault or protected variables, limit who can use each service connection and turn on secret scanning.

Both products continue to exist and are used together by many organizations. Microsoft invests heavily in GitHub, so check the current roadmap and guidance before making a long-term choice, and remember that you can mix the two.

Create an organization and a project, add your code to a repository, protect the main branch with a pull request policy, write a simple pipeline that builds and tests the code, and track your tasks on a board. Then add stages, approvals and security checks step by step.

Azure DevOps connects every step of building software, from the first idea to the live product. Boards plan and track the work, Repos keep the code and its history with pull requests and policies, Pipelines build, test and deliver automatically, Test Plans support human testing and Artifacts share packages. You have seen how organizations, projects and permissions are arranged, how branching and reviews protect quality, how YAML pipelines, agents, environments and approvals form a safe release path, and how service connections, Key Vault and security scanning protect secrets and code. You have also learned how metrics guide improvement, how Azure DevOps relates to GitHub, and how costs are controlled.

The best way to begin is small: protect the main branch, add a simple automated build and test, track work on a board, and release a little at a time. Then add stages, approvals, security checks and measurements as your confidence grows. DevOps is less about tools than about teamwork, fast feedback and steady improvement, and Azure DevOps gives your team a strong place to practice it.