Azure DevOps

Technical Definition

Azure DevOps is a suite of services comprising Azure Boards (work item tracking and agile planning), Azure Repos (Git or Team Foundation Version Control source hosting), Azure Pipelines (build and release automation, YAML or classic), Azure Test Plans (manual and exploratory test management) and Azure Artifacts (package feeds for NuGet, npm, Maven and universal packages). It is offered as the hosted Azure DevOps Services (multi-tenant SaaS) and as Azure DevOps Server (self-hosted, formerly Team Foundation Server). Access is governed by organisation- and project-level permissions, security groups and, for pipelines, service connections that scope credentials to specific target environments.

Operational Relevance

In day-to-day operations, Azure DevOps is the system of record for planned work and the control plane for delivery: pipeline definitions determine what gets built and where it is deployed, branch policies determine what code can merge, and service connections determine what external systems a pipeline may reach. Operational risk concentrates around three points: overly broad service connection scopes, pipeline YAML that runs on unreviewed pull requests, and shared build agents that retain state between runs. Observable operational health includes pipeline success rate, mean time from commit to deployed release, and the age and permission scope of active service connections.

Architecture Relationship

Azure DevOps sits between source control and target infrastructure. Azure Repos or an external Git provider supplies source; Azure Pipelines orchestrates build agents (Microsoft-hosted or self-hosted) that compile, test and package the change; Azure Artifacts stores the resulting packages; and Azure Pipelines then deploys to targets such as Azure App Service, Azure Kubernetes Service, virtual machines or on-premises servers via deployment groups. Azure Boards links work items to commits, pull requests and builds, giving traceability from a planned task to the pipeline run that delivered it. Identity is typically federated through Microsoft Entra ID, and pipeline access to Azure resources is commonly brokered through workload identity federation or service principals scoped by service connection.

Example

A team defines a YAML pipeline in Azure Repos that triggers on pull request completion into the main branch. The pipeline runs unit tests on a Microsoft-hosted agent, publishes a package to an Azure Artifacts feed, and then deploys to a staging App Service using a service connection scoped only to that resource group. A required reviewer policy on the main branch ensures no unreviewed code reaches the pipeline trigger.

Common Misunderstanding

A frequent misunderstanding is treating Azure DevOps and Azure Pipelines as interchangeable. Azure Pipelines is one component; Azure DevOps also includes Boards, Repos, Test Plans and Artifacts, and an organisation may use only a subset of these while still calling the whole platform “Azure DevOps”. Another common error is assuming a service connection’s permissions are limited to what the pipeline author intended; the actual limiting factor is how the connection was scoped when created, which requires separate verification in Azure DevOps project settings.

Related Terms

• Azure Pipelines
• Azure Repos
• Service connection
• Microsoft Entra ID
• CI/CD

Further Reading and Verification

For authoritative and current detail, consult the official Azure DevOps documentation directly, since pipeline YAML syntax, permission models and service connection authentication options are revised between releases. Confirm the specific Azure DevOps Services or Azure DevOps Server version in use before relying on any version-specific configuration detail, and validate service connection scope and pipeline permissions in a non-production project before applying changes to a production organisation.