About projects and scaling your organization
TFS 2017 | TFS 2015 | TFS 2013
A project provides a repository for source code and a place for users to plan, track progress, and collaborate on building software solutions. A project represents a fundamental container where data is stored when added to Azure DevOps.
When you create your project, a team of the same name is automatically created. This is sufficient for small teams. However, for enterprise-level organizations, it may be necessary to scale up, to create additional teams and projects. These additions can be created within the single account or collection.
Single project and team defined within an
organization or collection
Multiple projects and teams defined within an
organization or collection
The collection-project-team structure provides teams a high level of autonomy to configure their tools in ways that work for them. It also supports administrative tasks to occur at the appropriate level. As your organization grows, your tools can grow to support a culture of team autonomy and organizational alignment.
How do you manage work across the enterprise?
How do you scale your DevOps and Agile tools to support your growing enterprise?
When you connect to Azure DevOps, you connect to an organization or project collection. Within that container, one or more projects may be defined. At least one project must be created to use the system.
You can scale your on-premises Azure DevOps deployment in the following ways:
- To increase performance, you can add server instances
- To support different business units, you can add project collections and projects
- Within a project, you can add teams
- Add repositories and branches
- To support continuous integration and deployment, you can add agents, agent pools, and deployment pools
- To manage a large number of users, you can manage access through Active Directory
Azure DevOps Services and Azure DevOps Server are enterprise-ready platforms. These platforms support teams of any size, from tens to thousands. Azure DevOps Services, our cloud service, provides a scalable, reliable, and globally available hosted service. It's backed by a 99.9% SLA, monitored by our 24x7 operations team, and available in local data centers around the world.
How to view projects
You can view the projects defined for your organization by opening the Projects page.
Select
Azure DevOps to open Projects.
From there, you can choose a project from the set of projects listed.
When to add another project
In general, we recommend that you use a single project to support your organization or enterprise. A single project minimizes the maintenance of administrative tasks and supports the most optimized / full-flexibility cross-link object experience.
Even if you have many teams working on hundreds of different applications and software projects, you can most easily manage them within a single project. A project serves to isolate data stored within it. You can't easily move data from one project to another. When you move data from one project to another, you typically lose the history associated with that data.
For more information about when to add another project, see How many projects do you need?.
Reasons to add another project
You may want to add another project in following instances:
- To prohibit or manage access to the information contained within a project
- To support custom work tracking processes for specific business units within your organization
- To support entirely separate business units that have their own administrative policies and administrators
- To support testing customization activities or adding extensions before rolling out changes to the working project
Structure your project
When you add a project, look at using the following elements to structure it to support your business needs:
- Create a Git repository for each subproject or application, or create root folders within a TFVC repository for each subproject. If you're using TFVC and heading toward a combined project model, create root folders for different teams and projects, just as you would create separate repos in Git. Folders can be secured as needed and workspace mappings can control what segments of the repo you're actively using.
- Define area paths to support different subprojects, products, features, or teams.
- Define iteration paths (also known as sprints) that can be shared across teams.
- Add a team for each product team that develops a set of features for a product. Each team you create automatically creates a security group for that team, which you can use to manage permissions for a team. See also, Portfolio management.
- Grant or restrict access to select features and functions using custom security groups.
- Create query folders to organize queries for teams or product areas into folders.
- Define or modify notifications set at the project level.
Customizing and configuring projects
You can configure and customize most services and applications to support your business needs or the way your teams work. Within each project, you can do the following tasks. For a comprehensive view of what resources can be configured, see About team, project, and organizational-level settings.
- Dashboards: Each team can configure their set of dashboards to share information and monitor their progress.
- Source control: For each Git repository, you can apply branch policies and define branch permissions. For TFVC repositories, you can set check-in policies.
- Work tracking: You can add fields, change the workflow, add custom rules, and add custom pages to the work item form of most work item types. You can also add custom work item types. For details, see Customize the On-premises XML process model.
- Build and Release: You can fully customize your build and release pipelines, define build steps, release environments, and deployment schedule. For details, see Build and Release.
- Test: You can define and configure test plans, test suites, test cases, and test environments. You can also add test steps within your build pipelines. For details, see Exploratory & Manual Testing and continuous testing for your builds.
When to add a team, scaling Agile tools across the enterprise
As your organization grows, add teams to provide them the Agile tools that each team can configure to meet their workflow. To learn more, see the following articles.
- Scale Agile to large teams
- About teams and Agile tools
- Manage a portfolio of backlogs and gain insight into each team's progress and the progress of all programs.
- Use Delivery plans to review the schedule of stories or features your teams plan to deliver. Delivery plans show the scheduled work items by sprint (iteration path) of selected teams against a calendar view.
- Incrementally adopt practices that scale to create greater rhythm and flow within your organization, engage customers, improve project visibility, and develop a productive workforce.
- Structure projects to gain visibility across teams or to support epics, release trains, and multiple backlogs to support the Scaled Agile Framework.
To review stories and short videos on how Microsoft transitioned from waterfall to Agile, see Scaling Agile Across the Enterprise.
Clients that support connection to a project
In addition to connecting through a web browser, you can connect to a project from the following clients:
- Visual Studio (Professional, Enterprise, Test Professional)
- Visual Studio Code
- Visual Studio Community
- Eclipse: Team Explorer Everywhere
- Office Excel
- Azure Test Plans (formerly Test Manager)
- Microsoft Feedback Client
See also, Compatibility with Azure DevOps Server versions.
Q & A
Q: Can I move or transfer a project to another organization or collection?
A: Not without losing data. You can't move a project from one collection/organization to another collection/organization without losing data. You can manually copy resources and leave some behind, or use a third-party tool, such as OpsHub Visual Studio Migration Utility, that copies data using the REST APIs.
Q: What programmatic tools support projects?
A. See Projects REST API.