Introduction

Microsoft Visual Studio Team Foundation Server provides a set of integrated tools enabling Teams to effectively manage the life cycle of their software project. The Team in Team Foundation Server is encapsulated within the container of a Team Project. Simply put, Team Project is a logical container isolating all tools and artifacts associated with a software application together in a single namespace.

The conceptual boundary introduced through Team Project eliminates the problem of having access to unrelated artifacts such as code, Work Items, or release information not relevant to your applications development. Related Team Projects can be grouped together into a Team Project Collection. It can be used to introduce a physical separation between the groups of related Team Projects by hosting them in separate databases.

Team Foundation Server supports multiple Team Project Collections, each of which can internally host multiple Team Projects. Resources such as build pools are scoped at the Team Project Collection level. A Team Project can host multiple Teams; certain resources are set at the Team Project level and others at the Team level. As illustrated in the following screenshot, the selection of a source control repository (TFVC or Git) is made at the Team Project level; however, Teams have autonomy on the level of backlogs they choose and the workflows on the Kanban board. The delivery framework of choice is applied through the Process Template; this in turn applies the delivery framework-specific terminology, artifacts, and workflows to the Team Project and all Teams within the Team Project:

TFS Reporting warehouse is a traditional data warehouse consisting of a relational database organized in an approximate star schema and an SQL Server Analysis Services cube built on top of the relational database. All Team Projects, irrespective of the Team Project Collection they belong to, are aggregated into a single data warehouse.

Team Foundation Server provides a hierarchical security model. Permissions can be set through TFS Groups or AD Group membership through every level, right from the server through to the object level. Groups can be nested and set to inherit permissions through the hierarchy. Inheritance of permissions can be set to Denied where you want to control access to selected resources. A more in-depth breakdown of precreated groups with details of access and permissions can be found at http://bit.ly/1PPaU6l.

Permissions can be used to limit access to resources within or between Team Projects, Team Project Collections provide an isolation altogether. Team Project Collections also provide other functional and technical benefits such as:

• The usage of a single TFS instance across multiple departments while still providing a level of isolation. Collections can be used to reflect an organizational structure too.
• Flexibility in backup and restore. This can reduce downtime as restoring one collection will not impact users of other collections.
• Scalability and load balancing by moving collections on separate SQL Server instances.

In this chapter, we'll touch on Administration and Process Templates; these topics are discussed at length in future chapters. The focus of this chapter is on creating and setting up various elements of a Team Project.