Setting Up Azure DevOps: Organizations, Users, Pipelines, Agents, and Service Connections

Azure DevOps can be used as a standalone development and delivery platform for source control, project tracking, testing, artifact management, and CI/CD automation.

An Azure DevOps organization is not an Azure resource and does not reside inside an Azure subscription or resource group. However, it can be connected to Microsoft Entra ID for identity management and linked to an Azure subscription for billing.

Azure DevOps Hierarchy

The basic hierarchy is:

Microsoft Entra tenant → Azure DevOps organization → Projects → Repositories, pipelines, boards, artifacts, and test plans

An organization can contain multiple projects, and each project can have its own:

• Git repositories
• Build and deployment pipelines
• Service connections
• Variable groups
• Agent pools
• Azure Boards
• Artifacts
• Security groups and permissions

Quick Setup

1. Create the Azure DevOps Organization

Go to:

https://dev.azure.com

Sign in with the Microsoft Entra account that should own the organization, and select Create organization.

Define:

• Organization name
• Hosting geography
• Initial project name
• Project visibility
• Version-control system
• Work-item process

For most enterprise implementations, the initial project should be private.

You do not need to enable paid billing simply to create an organization and use its basic free services. However, the organization may need to be connected to a valid Azure subscription before its free Microsoft-hosted pipeline capacity becomes available.

2. Connect the Organization to Microsoft Entra ID

For enterprise environments, connect the Azure DevOps organization to the client’s Microsoft Entra tenant.

Navigate to:

Organization settings → Microsoft Entra ID

Connecting Azure DevOps to Entra ID provides:

• Single sign-on
• Centralized user management
• Conditional Access support
• Multifactor authentication
• Easier onboarding and offboarding
• Integration with Entra security groups
• Better control of guest and external users

Microsoft recommends this connection for enterprise identity and access management.

3. Create the Initial Project

Create a project for the application, platform, landing zone, or infrastructure deployment.

A practical project structure might include:

• Platform-Engineering
• Azure-Landing-Zone
• Application-Modernization
• Infrastructure-as-Code
• Security-Automation

Avoid creating one project for every small application unless separate administration, security, billing, or compliance boundaries justify it.

Add Users and Assign Permissions

Add users through:

Organization settings → Users

Assign the appropriate access level:

• Stakeholder – Limited access, primarily for work-item participation
• Basic – Boards, Repos, Pipelines, and general development capabilities
• Basic + Test Plans – Basic features plus advanced manual and exploratory testing
• Visual Studio Subscriber – Entitlements are determined by the user’s Visual Studio subscription

Visual Studio subscribers should be assigned the corresponding Visual Studio access level so Azure DevOps can recognize their existing benefits.

Do Not Make Every User an Administrator

Users should not automatically be added to Project Administrators.

Use least-privilege assignments:

• Add developers to Contributors.
• Add readers and auditors to Readers.
• Add business participants to appropriate Boards groups.
• Add build administrators only when they must manage pipelines or agent pools.
• Reserve Project Administrators for the small number of people responsible for project-wide configuration.
• Reserve Project Collection Administrators for organization-level administrators.

Where possible, manage access through Microsoft Entra groups instead of assigning permissions separately to individual users.

To add approved administrators:

Project settings → Permissions → Project Administrators → Members → Add

Configure Azure Repos

Open Repos and use the repository dropdown at the top of the page to:

• Select an existing repository
• Create a new repository
• Import a repository
• Clone a repository
• Manage repository-level security

Azure Repos provides unlimited private Git repositories under the Basic plan.

Recommended repository controls include:

• Protecting primary branches
• Requiring pull requests
• Requiring reviewer approval
• Preventing direct pushes to protected branches
• Requiring successful builds before merging
• Enabling comment resolution
• Defining required reviewers for sensitive folders
• Restricting force pushes
• Using branch naming and commit-message standards

Visual Studio Integration

Visual Studio integrates directly with Azure Repos.

A developer can:

1. Sign in to Visual Studio using the approved Microsoft Entra account.
2. Open Git → Clone Repository.
3. Select the Azure DevOps organization and project, or enter the repository clone URL.
4. Clone the repository locally.
5. Create branches, commit changes, push code, and open pull requests.

Before implementation, confirm whether the client uses:

• Visual Studio or Visual Studio Code
• Git Credential Manager
• HTTPS or SSH authentication
• Microsoft Entra authentication
• Existing Visual Studio subscriptions
• GitHub, Azure Repos, or another source-control platform

Personal Access Tokens should be used only where modern Microsoft Entra authentication is unavailable.

Create an Azure Service Connection

A service connection allows a pipeline to authenticate to Azure or another external system.

It does not run the pipeline agent. The agent executes the pipeline job; the service connection gives tasks within that job permission to access Azure resources.

Navigate to:

Project settings → Pipelines → Service connections → New service connection

Select:

Azure Resource Manager

For a new Azure connection, the preferred configuration is:

• Identity type: App registration
• Creation method: Automatic
• Credential: Workload identity federation

Workload identity federation avoids storing a client secret in Azure DevOps. Microsoft recommends it for new Azure Resource Manager service connections.

Select the Correct Scope

Supported scope levels include:

• Resource group, through a subscription-scoped connection restricted to a resource group
• Subscription
• Management group
• Azure Machine Learning workspace

Use the narrowest scope that supports the pipeline.

Recommended approach:

• Use resource-group scope for an application that deploys only into one resource group.
• Use subscription scope for subscription-wide platform deployments.
• Use management-group scope for enterprise landing zones, policies, or governance deployments spanning multiple subscriptions.
• Avoid the Tenant Root Group unless the pipeline genuinely requires tenant-wide authority.

A root-management-group service connection can affect every management group and subscription below it. Its permissions, pipeline authorization, approvals, and audit controls therefore require exceptional scrutiny.

Do not select Grant access permission to all pipelines unless every pipeline in the project should be able to use the connection. Microsoft recommends authorizing pipelines individually.

Use Separate Connections for Separate Environments

Create separate service connections for:

• Development
• Test
• Staging
• Production
• Shared platform services
• Management-group governance

For example:

• sc-azure-dev
• sc-azure-test
• sc-azure-prod
• sc-landing-zone-mg

Production connections should have stricter permissions, approvals, and pipeline-use restrictions.

Configure an Agent Pool

An agent is the compute environment that executes pipeline jobs.

Navigate to:

Organization settings → Agent pools

The principal agent options are:

Microsoft-Hosted Agents

Microsoft creates a temporary build machine for each job and removes it afterward.

Advantages:

• Minimal administration
• Clean environment for every run
• Built-in Windows, Linux, and macOS images
• Common build tools are already installed
• Good choice for general cloud-based builds

Limitations:

• Limited job duration and included monthly minutes
• No permanent local state
• Less control over installed software
• May not reach private networks without additional design
• Public outbound IP ranges can complicate firewall rules

Self-Hosted Agents

The organization installs and manages the agent on its own VM, physical server, container, or private-cloud resource.

Advantages:

• Access to private networks and on-premises systems
• Full control over installed software
• Persistent tool and package caches
• Custom security and compliance controls
• Potentially faster builds for specialized workloads

Limitations:

• The client owns patching and maintenance
• Capacity and scaling must be managed
• A compromised pipeline may affect a persistent agent
• Credentials and build artifacts must be cleaned carefully
• Network access must be tightly controlled

Avoid installing a self-hosted agent on a domain controller, administrator workstation, or critical production server.

Azure Virtual Machine Scale Set Agents

VM scale-set agents provide autoscaling within the client’s Azure subscription. They offer more control than Microsoft-hosted agents but require the client to manage the Azure infrastructure and base images.

Managed DevOps Pools

Managed DevOps Pools provide customizable, scalable agent infrastructure with less operational overhead than traditional self-hosted or VM scale-set agents. Microsoft describes the service as an evolution of VM scale-set agent pools.

They are useful when the organization needs:

• Private networking
• Custom images
• Autoscaling
• Better control over agent performance
• Reduced agent-infrastructure administration

Pipeline Parallelism and the Free Tier

A parallel job represents one pipeline job running at a time. It is a measure of concurrency—not the number of pipeline definitions the organization may create.

The Azure DevOps free tier currently includes:

• Five users with Basic access
• One Microsoft-hosted parallel job
• Up to 1,800 Microsoft-hosted minutes per month
• One self-hosted parallel job with unlimited minutes
• Azure Boards
• Unlimited private Azure Repos
• Two GiB of Azure Artifacts storage

Additional Microsoft-hosted parallel jobs are currently listed at $40 per job per month, while additional self-hosted parallel jobs are listed separately. Prices should always be confirmed against the client’s agreement and current Microsoft pricing.

The free tier does not mean that only one pipeline can be created. The organization can define multiple pipelines, but only the licensed number of jobs can execute concurrently.

Azure DevOps User Licensing

Current user-access options include:

Stakeholder

Free, but with restricted functionality. Appropriate for users who primarily review dashboards or participate in work-item processes.

Basic

The first five users are free. Additional Basic users are currently listed at $6 per user per month.

Basic + Test Plans

Includes advanced test-management capabilities and is currently listed at $52 per user per month.

Visual Studio Subscribers

Eligible Visual Studio subscriptions include Azure DevOps benefits. The organization should assign the correct Visual Studio access level rather than unnecessarily purchasing another Basic license.

Current published pricing is subject to the customer’s contract, currency, region, and Microsoft commercial agreement.

Pipeline Libraries and Variable Groups

Navigate to:

Pipelines → Library

Variable groups store values that can be shared across multiple pipelines.

Examples include:

• Azure region
• Resource-group name
• Environment name
• Subscription ID
• Application name
• Terraform backend settings
• Feature flags

There are two general variable types:

Pipeline Variables

Defined directly in a YAML pipeline or pipeline interface. These are local to that pipeline unless imported from a template or variable group.

Variable Groups

Created in the Library and reused across authorized pipelines.

Variable groups can also be linked to Azure Key Vault. This allows pipelines to retrieve secrets at runtime rather than storing them directly in Azure DevOps.

Never place passwords, client secrets, certificates, or access tokens directly in a YAML file or source repository.

Microsoft Commercial Agreement Types

The client’s Microsoft agreement affects how Azure and Azure DevOps charges are billed, but it does not fundamentally change the Azure DevOps project structure.

Pay-As-You-Go or Microsoft Customer Agreement

This is typically a direct, consumption-based Azure purchasing model. It is suitable for individuals, smaller organizations, proofs of concept, and organizations that do not require an Enterprise Agreement.

The older term Microsoft Online Subscription Program, or MOSP, may still appear in legacy discussions, but Microsoft Customer Agreement and current pay-as-you-go terminology are now more common.

Enterprise Agreement

An Enterprise Agreement is designed for larger organizations licensing Microsoft software and cloud services under a longer-term commercial agreement. Microsoft describes it as a minimum three-year licensing arrangement.

It can provide:

• Centralized enterprise purchasing
• Negotiated pricing
• Azure monetary commitments
• Department and account structures
• Enterprise billing and cost governance
• Coverage for qualifying software and cloud services

Cloud Solution Provider

Under the CSP model, the organization purchases Microsoft cloud services through an authorized Microsoft partner.

The partner may provide:

• Consolidated billing
• Licensing assistance
• Azure support
• Managed services
• Cost optimization
• Migration and operational services

CSP is a purchasing and partner-management channel—not simply a technical type of Azure subscription. Microsoft Customer Agreements are available through CSP partners.

Azure DevOps billing supports many subscriptions associated with EA, CSP, and pay-as-you-go arrangements.

Azure DevOps Billing Considerations

An Azure DevOps organization can operate independently of an Azure subscription while it remains within applicable free limits.

An Azure subscription must be connected when the organization needs to:

• Enable the free parallel-job grant
• Add more than five paid Basic users
• Purchase Basic + Test Plans
• Buy additional parallel jobs
• Pay for Azure Artifacts storage beyond the free allowance
• Purchase paid extensions or services

One Azure DevOps organization can be linked to only one Azure subscription for billing at a time. The same Azure subscription can, however, be used to bill multiple Azure DevOps organizations.

Questions to Ask the Client

Before configuring Azure DevOps, confirm the following.

Commercial and Billing

1. What Microsoft agreement is in place: pay-as-you-go/MCA, EA, or CSP?
2. Which Azure subscription should be used for Azure DevOps billing?
3. Who owns that subscription?
4. Are cost-center, purchase-order, or chargeback requirements involved?
5. How many paid users and parallel jobs are expected?

Identity and Access

6. Which Microsoft Entra tenant should own the organization?
7. Will external users or partner accounts require access?
8. Which Entra groups should map to Azure DevOps roles?
9. Who should be the organization owner?
10. Who genuinely requires Project Administrator or Project Collection Administrator access?
11. Are Conditional Access and MFA policies already defined?

Licensing

12. How many users require Basic access?
13. Who requires Basic + Test Plans?
14. Which users already have eligible Visual Studio subscriptions?
15. Are any users limited to Stakeholder access?

Repositories and Development Tools

16. Will the organization use Azure Repos, GitHub, or both?
17. Is existing source code being imported?
18. Will developers connect through Visual Studio or Visual Studio Code?
19. Are branch policies and pull-request approvals required?
20. Is secret scanning or another code-security platform required?

Pipelines and Agents

21. Will Microsoft-hosted, self-hosted, scale-set, or Managed DevOps Pool agents be used?
22. Do builds need access to private Azure resources or on-premises systems?
23. Which operating systems and development tools must be installed?
24. How many pipeline jobs must run concurrently?
25. Are fixed outbound IP addresses required?
26. Is there an existing build-agent image or hardening standard?

Azure Access

27. Which subscriptions, resource groups, or management groups will pipelines deploy into?
28. Should each environment use a separate service connection?
29. What RBAC roles should each deployment identity receive?
30. Will production deployments require approvals?
31. Will secrets be stored in Azure Key Vault?
32. Are privileged production deployments separated from development builds?

Recommended Security Baseline

A production-ready Azure DevOps implementation should include:

• Microsoft Entra ID integration
• Multifactor authentication
• Conditional Access where appropriate
• Group-based permission management
• Least-privilege service connections
• Workload identity federation instead of stored secrets
• Separate development and production identities
• Individual pipeline authorization for service connections
• Protected branches and required pull requests
• Production environment approvals and checks
• Azure Key Vault integration
• Restricted self-hosted agent network access
• Dependency and secret scanning
• Retention and audit-log requirements
• Periodic reviews of users, permissions, tokens, agents, and service connections

Azure DevOps Pipeline Audit

A formal pipeline audit may include approximately 65 hours of analysis and remediation planning, depending on the number and complexity of projects and pipelines.

The audit should cover:

• Inventory of organizations, projects, repositories, and pipelines
• Identification of critical deployment pipelines
• Review of YAML and classic pipelines
• Agent-pool architecture and security
• Service-connection authentication and RBAC
• Workload identity federation adoption
• Stored secrets and Personal Access Tokens
• Variable groups and Key Vault integration
• Branch policies and pull-request controls
• Pipeline permissions and approval gates
• Artifact handling and retention
• Build dependencies and third-party extensions
• Production deployment separation
• Logging, traceability, and audit evidence
• Pipeline concurrency and licensing
• Resilience, recovery, and ownership
• Custom PowerShell modules or scripts for Azure DevOps REST API analysis
• Prioritized findings and remediation roadmap

The final deliverables should include:

• Current-state inventory
• Risk-ranked findings
• Identity and permission matrix
• Service-connection assessment
• Agent-pool assessment
• Pipeline dependency map
• Licensing and cost observations
• Recommended target-state controls
• Remediation backlog
• Executive summary