English | EN 
Introduction
Azure DevOps(ADO) Services is for customers who are looking to deliver value to their user base through agile planning, continuous integration, continuous delivery and monitoring of applications. Azure DevOps can be used by companies and teams of different size ranging from small startups to huge corporations like Microsoft. Indeed, tens of thousands of engineers, program managers, and other stakeholders across Microsoft use Azure DevOps every day to deliver continuous value to customers.
In this blog, I will show you various scenarios and provides tailored guidance to use Azure DevOps for customers of different sizes and needs. First, let’s look at how Azure DevOps is organized.
Azure DevOps structure
You can create one or more Azure DevOps organizations. These organizations can be created using a Microsoft Account or with an Azure Active Directory-backed account. If your company utilizes Azure Active Directory, use the email address it’s associated with to create the Azure DevOps organization, so it is backed by that directory. In addition, you can use a single set of credentials to access multiple Microsoft online services (e.g. Office 365).
If you don’t have an Azure Active Directory, you can either create one for free from our Azure portal (http://portal.azure.com) or use your Microsoft account (e.g. XYZ@outlook.com) to create an Azure DevOps organization.
Company contoso has 4 organizations backed by their Contoso Azure Active Directory.
Each Azure DevOps organization contains one or more projects and each project provides access to the individual services: Azure Boards, Azure Repos, Azure Pipelines, Azure Test Plans, and Azure Artifacts.
E.g. Organization Contoso-Manufacturing has 3 projects
It is important to map organizations and projects to the right granularity of your organization and team structure. You have the following options:
- Mapping Azure DevOps organizations to business units (departments)
- Mapping Azure DevOps projects to business units (departments)
Let’s look at each approach in detail.
1. Mapping organizations to business units (departments)
Each business unit within your company gets its own Azure DevOps organization, and all are backed by the same Azure Active Directory. Projects can be set up, as required, based on either teams or ongoing work.
| Key Advantages: |
| Each organization can be set up in any of the supported regions. For example, you can set up one organization in the Western US and another organization in Europe, in proximity to where your business unit is located. This brings strong isolation and regional separation of your business unit’s assets. Access to these organizations can be restricted to users within those organizations. Each business unit can administer their own users, policies, access management, and billing practices for their organization. Each business unit can buy resources like pipelines (for CI/CD) and use them exclusively, managing costs independently. Resources can be shared across teams within those organizations. |
| Challenges: |
| Licenses only apply to a single organization. Users who access multiple organizations will need to purchase a license per organization. Each organization in the company is isolated from other organizations. Currently there are no features that work across organizational boundaries. (E.g. you cannot link a work item from one organization to another organization within your company.) Each team project collection on-premises will be mapped to an organization in Azure DevOps. Customers with multiple team project collections will end up with multiple organizations. |
2. Mapping projects to business units (departments)
Your company gets a single organization and sets up multiple projects with one or more projects representing a business unit. All Azure DevOps assets of the company are contained within this organization and located within a given region (e.g. Western Europe).
| Key Advantages: |
| Works well if all business units of your company are in the same geographical area. (e.g. the entire company is in North America)Works well if you don’t need to track budgets or spending per business unit.Work well if you don’t have any regulatory or compliance needs for geographical isolation of your Azure DevOps assets. |
| Challenges |
| Business units cannot administer their own users, policies, access management, or billing practices and require shared ownership of the organization.Business units must share resources, like pipelines (for CI/CD).Business units cannot track spending and billing separately.This will not work if you are migrating from on-premises with multiple collections since you will end up with multiple organizations with each collection on-premises mapped to a separate organization. |
Requirement scenarios
Let’s look at some of the common requirements I have heard of in the past and the provided guidance.
Organization Project Limits
Azure DevOps Services has a 300-project ‘soft limit’, meaning that if you have 300 projects there will not be any kind of blocker to stop from adding project 301, 302,… etc. There is a risk of overall Azure DevOps performance degradation when going over the suggested limit. However, project size, number of users, number of repos, overall activity, pipeline, etc. factor into this limit. As you can imagine, an org with 300 large, active projects may face performance issues where an org with 500 projects which are small or mostly archived will be unaffected.
Getting Started Documentation
The Community of Practice: Getting Started Documentation contains significant information including a quick start guide for admins and general users. If you are new to Azure DevOps Services, these pages are highly recommended.
