Microsoft Team Foundation Server Branching Guidance

NEW POST: Concurrent Development with single integration line

etropic — Thu, 06 Sep 2007 15:28:31 GMT

After reading this article, (and several others) I have a confusion that persists.

Perhaps I don't understand the intended scope of the dev..main..prod line, or perhaps I don't see the big picture. I see how this idea facilitates isolating development at the dev branch, but with a single integration branch, it does not isolate concurrent releases.

I see that the releases are branched under production, and this seems fine when the release has already been RELEASED.

In our environment, we may have several targets (v.1 v.2 v.3) where 1 is in current development and being released in time (v.1 v.1.1 v.1.2) but continuous to evolve at the current time. During this time version 2 may have some development to get it ready for beta. Code from v1 will be rolled into v2. But with a single integration line, we can never integrate v2 into main while v1 is still being working on in the dev and main lines.

It seems to me that either I've missed the scope of this line (maybe its much more micro than I think) or there needs to be several dev..main..prod lines off of some higher branch...

The second part I don't follow is this...

With a single production line how do you support multiple releases? I can see dev happening on the release 1 branch under production, but how does that code get back into sqa and release? Is the intent to create another dev..prod line under release 1 ?

It seems that the idea of an isolated dev..main..production is the entire point and reason for code isolation, but it "seems" to fall apart once you add any complexity. Why is it so important in the beginning, but not for maint of a release, or for dev of next beta.

Thank you for your time... one day here I'll wake up in the morning and it will dawn on me I'm sure!

NEW POST: Blocking branches

cesar5974314 — Mon, 23 Jul 2007 20:04:02 GMT

Hi,

I was wondering if there's some configuration to block certain branches during certain time of the development process. For example, my PROD branch should not be accessible for editing or merging until we reach the due date of new release. We've been having troubles with branch merging, mixing code up and having troubles when trying to fix it. I don't know if that solution could be possible. Maybe, instead of blocking, if there's some way to unable certain branches, that would be useful for me too. Thanks in advance.

Greetings,

César Campos

NEW POST: Feature Branch Life Cycle

jmarsch — Thu, 19 Jul 2007 17:05:23 GMT

I don't know about that. I had assume that you delete the branch when the feature is complete. One of the items in the anti-patterns section of the document reads that you might have a problem if you have branch that stays around for a long time, but its purpose keeps changing.

What to do probably depends upon your environment as well. I work in a small shop, where it is very possible that one developer might work on more than one feature at the same time. It could get a little confusing to have generically named feature branches when you are regularly changing hats ("Ok, today I am working on wonder-widget, is that FB1 or FB2?? Wait, wasn't FB2 the percalator feature??")

NEW POST: Bugfixing

amossin — Fri, 15 Jun 2007 08:21:06 GMT

After reading the Branching Guidance, it's still unclear to me how to incorporate and control bugfixes. For instance, after a release is done, we have a read-only safekeeping branch for release 1.0. When a bug is discovered in 1.0, where do we go from there? Do we open up the safekeeping branch? Do we do the fix in Production and then try to isolate the dll's or exe's that needs to be distributed as a hotfix? I guess there are two paths, if the bugfix is critical it would need to end up as some sort of hotfix or patch, if not it would make its way into the next release. Any advice on how to properly manage this? A few real-life examples would be great.

NEW POST: Real-life scenarios

amossin — Fri, 15 Jun 2007 08:12:25 GMT

The Branching Guidance has been a tremendous help for my company, in helping us to set up branches and builds in a meaningful way. However, for inexperienced users such as myself, I would very much like to see the addition of a few real-life scenarios. Either adding to the guide, or just as a discussion, would somebody be willing to share some insight into the real-world setups they have? I'm hoping this discussion can shed some light on some of the more practical aspects of branching, especially for small and inexperienced companies.

I can start off the discussion by sharing my first experience with branching in general, and this guide in particular. I will assume you have read the Guidance, and will frequently refer to concepts from it.

The company I work for is a small (5 developers) software vendor (enterprise search), and two weeks ago we had no branches, no formal releases, really ad-hoc builds, some unhappy customers, big versioning troubles, dll-hell...you probably get my drift. Our biggest challenge at this point is maintaining old releases (since we don't have any formal releases...), and controlling the quality of what gets delivered to customers. Most of the people I work with have no or limited experience with a professional build environment, and nobody have really cared until now. I have been wanting to do something about the situation in order to increase the quality of our product, and make our customers more happy with what we deliver. So I stumbled upon the Branching Guidance, and started to work out a strategy for how we were gonna do branching and versioning or our source code.

Being a really small company, I decided to go with a simple approach, similar to the first one described in the Guidance, consisting of three branches in addition to read-only safekeeping branches. Frankly, at this point I can't clearly understand the difference between an isolation strategy and a branching strategy. Is there a difference? To be honest, I don't see the need for a strategy at this point, because our first goal is just to have a proper release and versioning of our source code. Anyway, I believe we are using the branching strategy "Branch per component", because we are only two or three developers working on the component, and I don't think there needs to be a feature branch or a release branch for that.

I'm gonna start being a little more specific now, hopefully helping out others who are at the same stage. Our existing code base was branched into a new team project, under a folder called Development. This is now our development branch, so I setup a team build running unit tests (using the Test Tools Build Task which runs all unit tests in the solution, so that I didn't have to keep maintaining a test list). I created a new solution for the build called <ProductName>.Development.sln, the idea being to have a separate solution for each branch. In retrospect, I don't know if this is such a great idea, since I now wouldn't want to branch the dev-solution into Main. Do any others have experience or advice on how to do this?

This is as far as I've gotten, keep in mind I started the whole process about a week ago... At this point, I am going to ask all our developers to check in any changes they have in our old branch, and moving everyone over to the new, official Development branch. The old branch will be locked down for a little while, and then deleted when we are completely sure everything is in order. So the next step is going to be creating the Main branch. I'll do this by branching out Development, and then doing the same from Main to Production. I will be the only one with rights to check into Main and Production, and for a while I expect there to be no or little difference between the two. When this is done, I hopefully have a basic setup that will help us to better control our source code and enable proper releases and versions of our product. Then we will start planning and working towards our first proper release, following as much of the Guidance as we can along the way. Any advice would be greatly appreciated at this point.

So, please share your real-life scenarios and troubles, and let's help each other out!

NEW POST: Feature Branch Life Cycle

uTILLIty — Mon, 07 May 2007 06:01:52 GMT

From the naming in the whitepaper I assume the recommended practice is to use general names for FBs and re-use these after a feature has been reverse-merged into MAIN. Bugfixes from that point on must be made in MAIN (or a RELEASE-Branch), as the feature is now part of a release

NEW POST: When to start feature-branches

uTILLIty — Mon, 07 May 2007 05:58:33 GMT

For a web-application, for example, there must be a base already, for feature-branches to make sense. Or would you recommend counting the whole website as a "feature", and only additional satellite-dlls and applications to be counted as a feature?

UPDATED WIKI: Guidance for Structuring Team Projects

grahamba — Sat, 28 Apr 2007 00:18:19 GMT

Guidance for Structuring Team Projects

- Doug Neumann - Microsoft Corporation

Introduction

One of the most important considerations when looking to deploy Team Foundation Server within your organization is how you will employ the “Team Project” concept. It can be very tempting to jump in and immediately start creating Team Projects to satisfy every whim of the users in your organization. However, restructuring existing team projects is difficult to accomplish, so establishing a strategy for using team projects up front is very important. Careful forethought now can save you much pain down the road.
This whitepaper provides details on the components of a team project and discusses how those components may impact your decision about structuring your team projects. It also lays out a set of common strategies for employing team projects. Understanding this base of knowledge should empower you to make the best decision on how your organization will use team projects with Team Foundation Server (TFS).

What is a Team Project?

A TFS Team Project is a collection of artifacts that is used by a team of individuals to perform and track a related set of work. All artifacts stored in TFS belong to one and only one Team Project, and you cannot begin working in TFS until you have created at least one Team Project. Team Projects are created by a TFS administrator using the Team Project Creation Wizard.
The initial settings of a team project are governed by a process template. This template configures a new team project in accordance with a specific software development methodology that the people working on the team project will follow. TFS ships with support for two software development methodologies, but additional process templates can be added to the system, and all process templates can be extensively customized to fit the needs of your organization.

Components of a Team Project

Understanding artifacts being leveraged within your organization, the need for cross-organizational sharing of artifacts, and the available strategies for sharing TFS artifacts across team projects will lead you to the best decision about how to structure your team projects. The following table outlines the list of artifacts managed by TFS and the capabilities for sharing those artifacts between team projects.

Artifacts & Settings	Description	Considerations for Structuring Team Projects
Source Code	TFS manages your source code in its version control system. Each team project creates a top-level folder in the version control folder hierarchy and no other files or folders can be created in the root of the version control folder hierarchy. Every item created underneath a team project folder is “owned” by that team project.	Source code can be shared between team projects in various ways, including branching source from one team project into another and mapping source from another team into your workspace. TFS does not support the Visual SourceSafe style of file sharing where a single file can be manifested in multiple locations within the version control repository.
Work Items	Instances of work item types allow you to define and track the work being performed within your organization. When a new team project is established, an initial set of work items is created for you as defined in the process template used for that team project.	A work item belongs to the team project in which it was created and cannot be moved to another team project. Work items can, however, be copied to another team project, at which time the fields in the newly created work item are pre-populated with the value of the corresponding fields in the source work item. Currently, there is no mechanism for bulk-copying work items between team projects in TFS.
Work Item Types	The fields, form, and workflow of a TFS work item is governed by an XML definition known as the work item type. Work item types are defined in the process template used to create a team project and can be customized as necessary after the team project is created.	If you plan to track work across multiple projects using the reporting mechanisms in TFS, you’ll need to ensure sufficient consistency in the work items defined in those team projects. They do not need to be identical, but they need to share the set of fields being leveraged for these reports.
Work Item Queries	TFS persists a set of work item queries that provide a mechanism for team members to share views of the team’s work.	There is no way to structure work item queries in TFS beyond declaring them as Team queries or “My” queries. Large team projects with a lot of queries can make it difficult to find the queries users are interested in. This may encourage a more granular team project structure to minimize the number of queries that a single team project contains.
Team Build Types	Automated build definitions in TFS allow you to execute a build of your application(s) in a reproducible manner. Each team project has a collection of build “types” associated with it. Build types are persisted as files in the version control system.	By default, a single build type can only compile source from the team project in which it exists, however it is possible to modify the build definition to enlist source from outside of the team project.
Reports	Each team project creates a reporting site in SQL Reporting Services and a collection of reports that report on the progress and activity within that Team Project.	The data for all team projects on a given TFS exists in the same data warehouse, so it is possible to create custom reports that span multiple team projects. However, the reports included with TFS provide only a single-project view.
Team Portal	Each team project creates a Windows SharePoint Services portal to be used for collaborating within that team.	Team projects cannot share the same team portal, however if teams wish to collaborate with each other using the same portal, they can easily agree to use the portal created for one of the teams. SharePoint portals maintain their own set of security permissions if it’s necessary to govern portal permissions differently than other TFS permissions.
Process Guidance	Each team project portal contains a collection of web pages to provide guidance about how to follow the software development process being utilized.	Only one set of guidance exists for a given team project, however this typically does not influence the decision on how to structure team projects.
Area and Iteration Classifications	Area and iteration classifications provide a mechanism for you to decompose your application functionality and project timeline respectively. These classifications can then be applied to work items and other artifacts to make it easier to find the artifacts that are appropriate for a given area of the application or iteration of the timeline.	Area and iteration classifications are completely contained within the team project in which they are defined and cannot be shared between team projects. It is possible to manually replicate the area and iteration classifications between team projects if necessary. Also, the initial area and iteration hierarchy can be defined in the process template if standardization across team projects is desired.
Security Groups	TFS provides a mechanism for aggregating users into security groups for the purpose of controlling access to the system. Groups are defined at the server scope as well as the team project scope. TFS security groups can aggregate Windows user accounts, Windows groups and other TFS groups.	The security groups mechanism in TFS is quite flexible and is unlikely to influence your team project structure.
Check-in Policies	Checkin policies provide a mechanism for validating user changes to source code before they are committed to the system. Every team project defines a set of checkin policies that will apply to checkins in that team project.	Checkin policies cannot span multiple team projects, however policy definitions can be manually replicated to other team projects. Furthermore, checkin policies cannot be scoped to a subsection of the team project source, making it sometimes difficult to work with checkin policies when a team project contains a multitude of subteams. The Team Foundation Power Tools contain a checkin policy that can be used to scope other checkin policies to specific areas of the source tree.
Exclusive Check-out	A team project can specify whether files in version control will be locked when checked out or remain available for additional parallel checkouts.	Because the exclusive checkout setting is scoped to the entire team project, sub-teams wishing to work differently will need to come to an agreement about whether or not they’ll enable this feature.

Team Project Scalability

For some customers, the most important consideration in structuring team projects is the number of team projects that can co-exist on a TFS without significantly hindering server performance. Scalability of team projects is limited by the complexity of the work item types defined on the server. The work item types included in MSF for Agile Software Development have been shown to scale to support 500 team projects on a server. Similar testing with the work items in MSF for CMMI Process Improvement have been shown to support 250 team projects on a server. For more information about team project scalability, go here.

Strategies for Employing Team Projects

There is no one right way to structure your team projects, and your needs may change as your software development process evolves. That being said, there are 3 common strategies used to structure team projects. You may find that one of these strategies fills the needs of your organization or that you’ll choose a combination of these strategies as appropriate for the nature of your work.

Strategy 1: Team Project Per Application

The most common strategy for creating team projects is to create one for each application under development. This strategy can support both large and small applications, as well as multiple releases of applications being developed in parallel. Various releases of the application are manifested in the version control system as source branches, and in other parts of TFS as different nodes in the iteration classification hierarchy. If appropriate, documentation for each release that is stored in the SharePoint portal can be managed in different document libraries.
Following this strategy greatly simplifies the process of moving requirements, features, scenarios, and bugs between releases. When an item needs to be pushed out or brought it, it is signified by simply changing the iteration path to reflect the new target release.
The biggest drawback to this strategy is that the software development process for all releases of the application are tightly bound. For example, two releases of an application being developed in parallel would need to use the same work item types, the same checkin policies, and follow the same process guidance.
Another potential drawback is that you may need to customize the reports included with your process template to get an appropriate view of what is happening in a given release. Most reports included with the common process templates provide a team-project-wide view of what is happening; to get a view that is focused on a single release, you may need to add additional filtering for that release.
Over the course of multiple releases, you may find that your team project for a given application has developed a lot of “baggage.” This could include old work items that are no longer needed, old specs on the portal that should have been discarded, or old data in the data warehouse that could cloud your view of team progress. Additionally, you may decide at some point that you’d like to change your software development methodology and desire to retool your team project to support that methodology. At that time, you may find it is appropriate to create a new team project for this application, starting clean with a new process template, a new set of work items and a new project portal. You can then branch source from the previous team project to the new one, and copy work items as appropriate to the new team project.
Finally, an organization managing hundreds of small applications may eventually reach the scalability limits of TFS. For more information, see the previous subject on Team Project Scalability.

Strategy 2: Team Project Per Release

In the “Team Project Per Release” strategy, every major application release starts a new team project. This strategy works well for very large teams who are often working on long-term projects. For these teams, a major release is an opportunity to start clean with a new team project that doesn’t carry forward any baggage from the previous release. By starting with a new team project they can also select a different process template that supports a different development methodology than they had previously followed. They can also selectively move forward artifacts from the previous release to eliminate some of the baggage frequently left over from a multi-year effort. The team project from the current release can continue to be leveraged for maintenance activities on the release, potentially with a different team that is responsible for sustaining engineering.
The primary disadvantage with this strategy lies in the difficulty of moving data forward from one team project to the next. It is relatively easy to move source code between team projects, typically by branching the source into the new team project. Moving work items forward, however, is more difficult. TFS provides the ability to copy a work item from one team project to another, but that only works on one work item at a time. To copy a set of work items between team projects, you would need to write your own custom utility with the TFS object model.
Server scalability can also be a concern with this model, however usually organizations engaged in these projects find they are managing a few large efforts rather than many small efforts. The server scalability concerns related to structuring your team projects only come into play when managing hundreds of team projects on a Team Foundation Server. For specific scalability numbers, see the previous subject on Team Project Scalability.

Strategy 3: Team Project Per Team

For a few customers, the best way to structure team projects is to align them with the team boundaries in their organization. This strategy closely aligns a team with the workflows defined in TFS work item types and provides a unit of reporting that spans the entire team. For customers looking to centrally control and monitor the activities of software development teams, this may be the best approach.
This strategy can be a necessity when encountering the team project scalability limitations discussed previously. Organizations that manage several hundred applications may find that they need to group applications together under a fewer number of team projects. An appropriate criteria for grouping these applications is frequently to cluster together applications developed by the same team.
The primary disadvantage of this approach is that it precludes specialization of the software development process for a particular application or release. If one application in an organization needs a new field on a work item type, all applications will get that new field. Additionally, reports that show timeline details of the team project lose their value if the applications managed in the team project are not working toward the same timeline.

Providing Substructure Within a Team Project

Regardless of the strategy you choose, you will need to provide some level of substructure to your team project. If you select the team project per application model, you may need to create substructure for each release. If you are working on a very large application and select the team project per release model, you may need to establish substructure for subcomponents of the application. And if you select the team project per team model, you will probably need to establish substructure for the applications that the team works on.
The mechanisms for providing substructure depend on the type of artifact being managed. The following table discusses the substructure mechanisms for the artifacts and settings discussed previously.

Artifacts & Settings	Substructure Mechanisms
Source Code	The top level structure for source code within a team project is typically a “branch.” Branches in TFS appear as copies of the files and folders they are branched from. Frequently, the first thing you’ll do in source control for a new team project is to create a new folder with a name like “main” that constitutes the main branch for your source. Future branches would likely be made using that folder as the source. Within a branch, structure is typically provided with a folder hierarchy of your choosing. If you find you have a proliferation of branches, it is possible to group related branches underneath a single folder. For example, if you have several branches working in parallel for a given release, you may choose to create a folder for that release and then create your branches underneath that folder. If you’ve already created your branches and wish to reorganize them, you can move the root folder of the branch to the new location with the move operation.
Work Items	Work items are classified according to 2 dimensions: the area path and the iteration path. The area path classification can be used to classify work items for particular components within an application or applications within an application suite. The iteration path can be used to classify work items for a given release or a particular iteration of development within a release.
Work Item Types	There is no way to provide substructure to the list of work item types in a team project, however most team projects limit themselves to a few work item types and substructure is not needed.
Team Build Types	There is no way to provide substructure to the list of team build types in a team project, however it is uncommon to maintain an overwhelmingly long list of team build types. If you are building multiple applications within a given team project, it may be advisable to have several of them build with the same build type.
Reports	SQL Reporting Services allows for reports to be structured into folders. This folder structure is reflected into the Team Explorer in Visual Studio.
Team Portal	Sharepoint provides multiple options for structuring documents stored in the team portal. At the top level, multiple document libraries can be maintained for managing documents with different purposes (such as audiences). Each document library can maintain a unique metadata schema allowing you to track different information about documents based on the library in which they live. Beneath a document library, an arbitrary depth of folders can be established for further structure. Document libraries and the folder structure underneath them are both reflected in the Team Explorer in Visual Studio. At a higher level, sub-sites can also be created in Sharepoint for providing a customized portal for a subset of team project members. Sub-sites are not reflected into the Team Explorer in Visual Studio.
Process Guidance	The process guidance that exists on the team portal is a set of web pages describing the software development methodology being followed. If a subset of the members of a team project need customized guidance, it can be reflected on the existing process guidance pages, or a new set of pages can be created.
Area and Iteration Classifications	The area and iteration classifications are both hierarchies that can be structured as appropriate to represent the functional and temporal breakdown of your application respectively. As mentioned previously, if you are managing multiple applications in a team project, you’ll likely want the top level of the area hierarchy to reflect the applications being managed. Similarly, if you are representing multiple releases in a team project, you’ll likely want the top level of the iteration hierarchy to reflect the releases.
Security Groups	TFS provides a built-in security group mechanism that allows you to manage group membership in TFS rather than through Active Directory or the operating system. These groups can contain any arbitrary set of windows users, windows groups, or other TFS groups. As such, you can subdivide your team as necessary, define the needed groups to represent those subdivisions, and then create additional groups to aggregate those into larger lists of users.
Check-in Policies	Check-in policies are scoped to all source in a team project. This can make it challenging to manage a large source base in a team project because the policies you wish to define for one part of the source tree may not apply for another part of the source tree. The latest release of the Team Foundation Power Tools provides a check-in policy that can be used to scope other check-in policies to a subset of the source tree for a team project.
Exclusive Check-out	Exclusive checkout in version control can be enabled only at the team project level and not on a subsection of the team project source.

UPDATED WIKI: Guidance for Structuring Team Projects

grahamba — Thu, 26 Apr 2007 21:10:04 GMT

Guidance for Structuring Team Projects

- Doug Neumann - Microsoft Corporation

Introduction

What is a Team Project?

Components of a Team Project

Artifacts & Settings	Description	Considerations for Structuring Team Projects
Source Code	TFS manages your source code in its version control system. Each team project creates a top-level folder in the version control folder hierarchy and no other files or folders can be created in the root of the version control folder hierarchy. Every item created underneath a team project folder is “owned” by that team project.	Source code can be shared between team projects in various ways, including branching source from one team project into another and mapping source from another team into your workspace. TFS does not support the Visual SourceSafe style of file sharing where a single file can be manifested in multiple locations within the version control repository.
Work Items	Instances of work item types allow you to define and track the work being performed within your organization. When a new team project is established, an initial set of work items is created for you as defined in the process template used for that team project.	A work item belongs to the team project in which it was created and cannot be moved to another team project. Work items can, however, be copied to another team project, at which time the fields in the newly created work item are pre-populated with the value of the corresponding fields in the source work item. Currently, there is no mechanism for bulk-copying work items between team projects in TFS.
Work Item Types	The fields, form, and workflow of a TFS work item is governed by an XML definition known as the work item type. Work item types are defined in the process template used to create a team project and can be customized as necessary after the team project is created.	If you plan to track work across multiple projects using the reporting mechanisms in TFS, you’ll need to ensure sufficient consistency in the work items defined in those team projects. They do not need to be identical, but they need to share the set of fields being leveraged for these reports.
Work Item Queries	TFS persists a set of work item queries that provide a mechanism for team members to share views of the team’s work.	There is no way to structure work item queries in TFS beyond declaring them as Team queries or “My” queries. Large team projects with a lot of queries can make it difficult to find the queries users are interested in. This may encourage a more granular team project structure to minimize the number of queries that a single team project contains.
Team Build Types	Automated build definitions in TFS allow you to execute a build of your application(s) in a reproducible manner. Each team project has a collection of build “types” associated with it. Build types are persisted as files in the version control system.	By default, a single build type can only compile source from the team project in which it exists, however it is possible to modify the build definition to enlist source from outside of the team project.
Reports	Each team project creates a reporting site in SQL Reporting Services and a collection of reports that report on the progress and activity within that Team Project.	The data for all team projects on a given TFS exists in the same data warehouse, so it is possible to create custom reports that span multiple team projects. However, the reports included with TFS provide only a single-project view.
Team Portal	Each team project creates a Windows SharePoint Services portal to be used for collaborating within that team.	Team projects cannot share the same team portal, however if teams wish to collaborate with each other using the same portal, they can easily agree to use the portal created for one of the teams. SharePoint portals maintain their own set of security permissions if it’s necessary to govern portal permissions differently than other TFS permissions.
Process Guidance	Each team project portal contains a collection of web pages to provide guidance about how to follow the software development process being utilized.	Only one set of guidance exists for a given team project, however this typically does not influence the decision on how to structure team projects.
Area and Iteration Classifications	Area and iteration classifications provide a mechanism for you to decompose your application functionality and project timeline respectively. These classifications can then be applied to work items and other artifacts to make it easier to find the artifacts that are appropriate for a given area of the application or iteration of the timeline.	Area and iteration classifications are completely contained within the team project in which they are defined and cannot be shared between team projects. It is possible to manually replicate the area and iteration classifications between team projects if necessary. Also, the initial area and iteration hierarchy can be defined in the process template if standardization across team projects is desired.
Security Groups	TFS provides a mechanism for aggregating users into security groups for the purpose of controlling access to the system. Groups are defined at the server scope as well as the team project scope. TFS security groups can aggregate Windows user accounts, Windows groups and other TFS groups.	The security groups mechanism in TFS is quite flexible and is unlikely to influence your team project structure.
Check-in Policies	Checkin policies provide a mechanism for validating user changes to source code before they are committed to the system. Every team project defines a set of checkin policies that will apply to checkins in that team project.	Checkin policies cannot span multiple team projects, however policy definitions can be manually replicated to other team projects. Furthermore, checkin policies cannot be scoped to a subsection of the team project source, making it sometimes difficult to work with checkin policies when a team project contains a multitude of subteams. The Team Foundation Power Tools contain a checkin policy that can be used to scope other checkin policies to specific areas of the source tree.
Exclusive Check-out	A team project can specify whether files in version control will be locked when checked out or remain available for additional parallel checkouts.	Because the exclusive checkout setting is scoped to the entire team project, sub-teams wishing to work differently will need to come to an agreement about whether or not they’ll enable this feature.

Team Project Scalability

Strategies for Employing Team Projects

Strategy 1: Team Project Per Application

Strategy 2: Team Project Per Release

Strategy 3: Team Project Per Team

Providing Substructure Within a Team Project

Artifacts & Settings	Substructure Mechanisms
Source Code	The top level structure for source code within a team project is typically a “branch.” Branches in TFS appear as copies of the files and folders they are branched from. Frequently, the first thing you’ll do in source control for a new team project is to create a new folder with a name like “main” that constitutes the main branch for your source. Future branches would likely be made using that folder as the source. Within a branch, structure is typically provided with a folder hierarchy of your choosing. If you find you have a proliferation of branches, it is possible to group related branches underneath a single folder. For example, if you have several branches working in parallel for a given release, you may choose to create a folder for that release and then create your branches underneath that folder. If you’ve already created your branches and wish to reorganize them, you can move the root folder of the branch to the new location with the move operation.
Work Items	Work items are classified according to 2 dimensions: the area path and the iteration path. The area path classification can be used to classify work items for particular components within an application or applications within an application suite. The iteration path can be used to classify work items for a given release or a particular iteration of development within a release.
Work Item Types	There is no way to provide substructure to the list of work item types in a team project, however most team projects limit themselves to a few work item types and substructure is not needed.
Team Build Types	There is no way to provide substructure to the list of team build types in a team project, however it is uncommon to maintain an overwhelmingly long list of team build types. If you are building multiple applications within a given team project, it may be advisable to have several of them build with the same build type.
Reports	SQL Reporting Services allows for reports to be structured into folders. This folder structure is reflected into the Team Explorer in Visual Studio.
Team Portal	Sharepoint provides multiple options for structuring documents stored in the team portal. At the top level, multiple document libraries can be maintained for managing documents with different purposes (such as audiences). Each document library can maintain a unique metadata schema allowing you to track different information about documents based on the library in which they live. Beneath a document library, an arbitrary depth of folders can be established for further structure. Document libraries and the folder structure underneath them are both reflected in the Team Explorer in Visual Studio. At a higher level, sub-sites can also be created in Sharepoint for providing a customized portal for a subset of team project members. Sub-sites are not reflected into the Team Explorer in Visual Studio.
Process Guidance	The process guidance that exists on the team portal is a set of web pages describing the software development methodology being followed. If a subset of the members of a team project need customized guidance, it can be reflected on the existing process guidance pages, or a new set of pages can be created.
Area and Iteration Classifications	The area and iteration classifications are both hierarchies that can be structured as appropriate to represent the functional and temporal breakdown of your application respectively. As mentioned previously, if you are managing multiple applications in a team project, you’ll likely want the top level of the area hierarchy to reflect the applications being managed. Similarly, if you are representing multiple releases in a team project, you’ll likely want the top level of the iteration hierarchy to reflect the releases.
Security Groups	TFS provides a built-in security group mechanism that allows you to manage group membership in TFS rather than through Active Directory or the operating system. These groups can contain any arbitrary set of windows users, windows groups, or other TFS groups. As such, you can subdivide your team as necessary, define the needed groups to represent those subdivisions, and then create additional groups to aggregate those into larger lists of users.
Check-in Policies	Check-in policies are scoped to all source in a team project. This can make it challenging to manage a large source base in a team project because the policies you wish to define for one part of the source tree may not apply for another part of the source tree. The latest release of the Team Foundation Power Tools provides a check-in policy that can be used to scope other check-in policies to a subset of the source tree for a team project.
Exclusive Check-out	Exclusive checkout in version control can be enabled only at the team project level and not on a subsection of the team project source.

UPDATED WIKI: Guidance for Structuring Team Projects

grahamba — Thu, 26 Apr 2007 21:09:34 GMT

Guidance for Structuring Team Projects

- Doug Neumann - Microsoft Corporation

Introduction

What is a Team Project?

Components of a Team Project

Artifacts & Settings	Description	Considerations for Structuring Team Projects
Source Code	TFS manages your source code in its version control system. Each team project creates a top-level folder in the version control folder hierarchy and no other files or folders can be created in the root of the version control folder hierarchy. Every item created underneath a team project folder is “owned” by that team project.	Source code can be shared between team projects in various ways, including branching source from one team project into another and mapping source from another team into your workspace. TFS does not support the Visual SourceSafe style of file sharing where a single file can be manifested in multiple locations within the version control repository.
Work Items	Instances of work item types allow you to define and track the work being performed within your organization. When a new team project is established, an initial set of work items is created for you as defined in the process template used for that team project.	A work item belongs to the team project in which it was created and cannot be moved to another team project. Work items can, however, be copied to another team project, at which time the fields in the newly created work item are pre-populated with the value of the corresponding fields in the source work item. Currently, there is no mechanism for bulk-copying work items between team projects in TFS.
Work Item Types	The fields, form, and workflow of a TFS work item is governed by an XML definition known as the work item type. Work item types are defined in the process template used to create a team project and can be customized as necessary after the team project is created.	If you plan to track work across multiple projects using the reporting mechanisms in TFS, you’ll need to ensure sufficient consistency in the work items defined in those team projects. They do not need to be identical, but they need to share the set of fields being leveraged for these reports.
Work Item Queries	TFS persists a set of work item queries that provide a mechanism for team members to share views of the team’s work.	There is no way to structure work item queries in TFS beyond declaring them as Team queries or “My” queries. Large team projects with a lot of queries can make it difficult to find the queries users are interested in. This may encourage a more granular team project structure to minimize the number of queries that a single team project contains.
Team Build Types	Automated build definitions in TFS allow you to execute a build of your application(s) in a reproducible manner. Each team project has a collection of build “types” associated with it. Build types are persisted as files in the version control system.	By default, a single build type can only compile source from the team project in which it exists, however it is possible to modify the build definition to enlist source from outside of the team project.
Reports	Each team project creates a reporting site in SQL Reporting Services and a collection of reports that report on the progress and activity within that Team Project.	The data for all team projects on a given TFS exists in the same data warehouse, so it is possible to create custom reports that span multiple team projects. However, the reports included with TFS provide only a single-project view.
Team Portal	Each team project creates a Windows SharePoint Services portal to be used for collaborating within that team.	Team projects cannot share the same team portal, however if teams wish to collaborate with each other using the same portal, they can easily agree to use the portal created for one of the teams. SharePoint portals maintain their own set of security permissions if it’s necessary to govern portal permissions differently than other TFS permissions.
Process Guidance	Each team project portal contains a collection of web pages to provide guidance about how to follow the software development process being utilized.	Only one set of guidance exists for a given team project, however this typically does not influence the decision on how to structure team projects.
Area and Iteration Classifications	Area and iteration classifications provide a mechanism for you to decompose your application functionality and project timeline respectively. These classifications can then be applied to work items and other artifacts to make it easier to find the artifacts that are appropriate for a given area of the application or iteration of the timeline.	Area and iteration classifications are completely contained within the team project in which they are defined and cannot be shared between team projects. It is possible to manually replicate the area and iteration classifications between team projects if necessary. Also, the initial area and iteration hierarchy can be defined in the process template if standardization across team projects is desired.
Security Groups	TFS provides a mechanism for aggregating users into security groups for the purpose of controlling access to the system. Groups are defined at the server scope as well as the team project scope. TFS security groups can aggregate Windows user accounts, Windows groups and other TFS groups.	The security groups mechanism in TFS is quite flexible and is unlikely to influence your team project structure.
Check-in Policies	Checkin policies provide a mechanism for validating user changes to source code before they are committed to the system. Every team project defines a set of checkin policies that will apply to checkins in that team project.	Checkin policies cannot span multiple team projects, however policy definitions can be manually replicated to other team projects. Furthermore, checkin policies cannot be scoped to a subsection of the team project source, making it sometimes difficult to work with checkin policies when a team project contains a multitude of subteams. The Team Foundation Power Tools contain a checkin policy that can be used to scope other checkin policies to specific areas of the source tree.
Exclusive Check-out	A team project can specify whether files in version control will be locked when checked out or remain available for additional parallel checkouts.	Because the exclusive checkout setting is scoped to the entire team project, sub-teams wishing to work differently will need to come to an agreement about whether or not they’ll enable this feature.

Team Project Scalability

Strategies for Employing Team Projects

Strategy 1: Team Project Per Application

Strategy 2: Team Project Per Release

Strategy 3: Team Project Per Team

Providing Substructure Within a Team Project

Artifacts & Settings	Substructure Mechanisms
Source Code	The top level structure for source code within a team project is typically a “branch.” Branches in TFS appear as copies of the files and folders they are branched from. Frequently, the first thing you’ll do in source control for a new team project is to create a new folder with a name like “main” that constitutes the main branch for your source. Future branches would likely be made using that folder as the source. Within a branch, structure is typically provided with a folder hierarchy of your choosing. If you find you have a proliferation of branches, it is possible to group related branches underneath a single folder. For example, if you have several branches working in parallel for a given release, you may choose to create a folder for that release and then create your branches underneath that folder. If you’ve already created your branches and wish to reorganize them, you can move the root folder of the branch to the new location with the move operation.
Work Items	Work items are classified according to 2 dimensions: the area path and the iteration path. The area path classification can be used to classify work items for particular components within an application or applications within an application suite. The iteration path can be used to classify work items for a given release or a particular iteration of development within a release.
Work Item Types	There is no way to provide substructure to the list of work item types in a team project, however most team projects limit themselves to a few work item types and substructure is not needed.
Team Build Types	There is no way to provide substructure to the list of team build types in a team project, however it is uncommon to maintain an overwhelmingly long list of team build types. If you are building multiple applications within a given team project, it may be advisable to have several of them build with the same build type.
Reports	SQL Reporting Services allows for reports to be structured into folders. This folder structure is reflected into the Team Explorer in Visual Studio.
Team Portal	Sharepoint provides multiple options for structuring documents stored in the team portal. At the top level, multiple document libraries can be maintained for managing documents with different purposes (such as audiences). Each document library can maintain a unique metadata schema allowing you to track different information about documents based on the library in which they live. Beneath a document library, an arbitrary depth of folders can be established for further structure. Document libraries and the folder structure underneath them are both reflected in the Team Explorer in Visual Studio. At a higher level, sub-sites can also be created in Sharepoint for providing a customized portal for a subset of team project members. Sub-sites are not reflected into the Team Explorer in Visual Studio.
Process Guidance	The process guidance that exists on the team portal is a set of web pages describing the software development methodology being followed. If a subset of the members of a team project need customized guidance, it can be reflected on the existing process guidance pages, or a new set of pages can be created.
Area and Iteration Classifications	The area and iteration classifications are both hierarchies that can be structured as appropriate to represent the functional and temporal breakdown of your application respectively. As mentioned previously, if you are managing multiple applications in a team project, you’ll likely want the top level of the area hierarchy to reflect the applications being managed. Similarly, if you are representing multiple releases in a team project, you’ll likely want the top level of the iteration hierarchy to reflect the releases.
Security Groups	TFS provides a built-in security group mechanism that allows you to manage group membership in TFS rather than through Active Directory or the operating system. These groups can contain any arbitrary set of windows users, windows groups, or other TFS groups. As such, you can subdivide your team as necessary, define the needed groups to represent those subdivisions, and then create additional groups to aggregate those into larger lists of users.
Check-in Policies	Check-in policies are scoped to all source in a team project. This can make it challenging to manage a large source base in a team project because the policies you wish to define for one part of the source tree may not apply for another part of the source tree. The latest release of the Team Foundation Power Tools:http://go.microsoft.com/?linkid=5422499 provides a check-in policy that can be used to scope other check-in policies to a subset of the source tree for a team project.
Exclusive Check-out	Exclusive checkout in version control can be enabled only at the team project level and not on a subsection of the team project source.

UPDATED WIKI: Guidance for Structuring Team Projects

grahamba — Thu, 26 Apr 2007 21:08:28 GMT

Guidance for Structuring Team Projects

- Doug Neumann - Microsoft Corporation

Introduction

What is a Team Project?

Components of a Team Project

Artifacts & Settings	Description	Considerations for Structuring Team Projects
Source Code	TFS manages your source code in its version control system. Each team project creates a top-level folder in the version control folder hierarchy and no other files or folders can be created in the root of the version control folder hierarchy. Every item created underneath a team project folder is “owned” by that team project.	Source code can be shared between team projects in various ways, including branching source from one team project into another and mapping source from another team into your workspace. TFS does not support the Visual SourceSafe style of file sharing where a single file can be manifested in multiple locations within the version control repository.
Work Items	Instances of work item types allow you to define and track the work being performed within your organization. When a new team project is established, an initial set of work items is created for you as defined in the process template used for that team project.	A work item belongs to the team project in which it was created and cannot be moved to another team project. Work items can, however, be copied to another team project, at which time the fields in the newly created work item are pre-populated with the value of the corresponding fields in the source work item. Currently, there is no mechanism for bulk-copying work items between team projects in TFS.
Work Item Types	The fields, form, and workflow of a TFS work item is governed by an XML definition known as the work item type. Work item types are defined in the process template used to create a team project and can be customized as necessary after the team project is created.	If you plan to track work across multiple projects using the reporting mechanisms in TFS, you’ll need to ensure sufficient consistency in the work items defined in those team projects. They do not need to be identical, but they need to share the set of fields being leveraged for these reports.
Work Item Queries	TFS persists a set of work item queries that provide a mechanism for team members to share views of the team’s work.	There is no way to structure work item queries in TFS beyond declaring them as Team queries or “My” queries. Large team projects with a lot of queries can make it difficult to find the queries users are interested in. This may encourage a more granular team project structure to minimize the number of queries that a single team project contains.
Team Build Types	Automated build definitions in TFS allow you to execute a build of your application(s) in a reproducible manner. Each team project has a collection of build “types” associated with it. Build types are persisted as files in the version control system.	By default, a single build type can only compile source from the team project in which it exists, however it is possible to modify the build definition to enlist source from outside of the team project.
Reports	Each team project creates a reporting site in SQL Reporting Services and a collection of reports that report on the progress and activity within that Team Project.	The data for all team projects on a given TFS exists in the same data warehouse, so it is possible to create custom reports that span multiple team projects. However, the reports included with TFS provide only a single-project view.
Team Portal	Each team project creates a Windows SharePoint Services portal to be used for collaborating within that team.	Team projects cannot share the same team portal, however if teams wish to collaborate with each other using the same portal, they can easily agree to use the portal created for one of the teams. SharePoint portals maintain their own set of security permissions if it’s necessary to govern portal permissions differently than other TFS permissions.
Process Guidance	Each team project portal contains a collection of web pages to provide guidance about how to follow the software development process being utilized.	Only one set of guidance exists for a given team project, however this typically does not influence the decision on how to structure team projects.
Area and Iteration Classifications	Area and iteration classifications provide a mechanism for you to decompose your application functionality and project timeline respectively. These classifications can then be applied to work items and other artifacts to make it easier to find the artifacts that are appropriate for a given area of the application or iteration of the timeline.	Area and iteration classifications are completely contained within the team project in which they are defined and cannot be shared between team projects. It is possible to manually replicate the area and iteration classifications between team projects if necessary. Also, the initial area and iteration hierarchy can be defined in the process template if standardization across team projects is desired.
Security Groups	TFS provides a mechanism for aggregating users into security groups for the purpose of controlling access to the system. Groups are defined at the server scope as well as the team project scope. TFS security groups can aggregate Windows user accounts, Windows groups and other TFS groups.	The security groups mechanism in TFS is quite flexible and is unlikely to influence your team project structure.
Check-in Policies	Checkin policies provide a mechanism for validating user changes to source code before they are committed to the system. Every team project defines a set of checkin policies that will apply to checkins in that team project.	Checkin policies cannot span multiple team projects, however policy definitions can be manually replicated to other team projects. Furthermore, checkin policies cannot be scoped to a subsection of the team project source, making it sometimes difficult to work with checkin policies when a team project contains a multitude of subteams. The Team Foundation Power Tools contain a checkin policy that can be used to scope other checkin policies to specific areas of the source tree.
Exclusive Check-out	A team project can specify whether files in version control will be locked when checked out or remain available for additional parallel checkouts.	Because the exclusive checkout setting is scoped to the entire team project, sub-teams wishing to work differently will need to come to an agreement about whether or not they’ll enable this feature.

Team Project Scalability

Strategies for Employing Team Projects

Strategy 1: Team Project Per Application

Strategy 2: Team Project Per Release

Strategy 3: Team Project Per Team

Providing Substructure Within a Team Project

Artifacts & Settings	Substructure Mechanisms
Source Code	The top level structure for source code within a team project is typically a “branch.” Branches in TFS appear as copies of the files and folders they are branched from. Frequently, the first thing you’ll do in source control for a new team project is to create a new folder with a name like “main” that constitutes the main branch for your source. Future branches would likely be made using that folder as the source. Within a branch, structure is typically provided with a folder hierarchy of your choosing. If you find you have a proliferation of branches, it is possible to group related branches underneath a single folder. For example, if you have several branches working in parallel for a given release, you may choose to create a folder for that release and then create your branches underneath that folder. If you’ve already created your branches and wish to reorganize them, you can move the root folder of the branch to the new location with the move operation.
Work Items	Work items are classified according to 2 dimensions: the area path and the iteration path. The area path classification can be used to classify work items for particular components within an application or applications within an application suite. The iteration path can be used to classify work items for a given release or a particular iteration of development within a release.
Work Item Types	There is no way to provide substructure to the list of work item types in a team project, however most team projects limit themselves to a few work item types and substructure is not needed.
Team Build Types	There is no way to provide substructure to the list of team build types in a team project, however it is uncommon to maintain an overwhelmingly long list of team build types. If you are building multiple applications within a given team project, it may be advisable to have several of them build with the same build type.
Reports	SQL Reporting Services allows for reports to be structured into folders. This folder structure is reflected into the Team Explorer in Visual Studio.
Team Portal	Sharepoint provides multiple options for structuring documents stored in the team portal. At the top level, multiple document libraries can be maintained for managing documents with different purposes (such as audiences). Each document library can maintain a unique metadata schema allowing you to track different information about documents based on the library in which they live. Beneath a document library, an arbitrary depth of folders can be established for further structure. Document libraries and the folder structure underneath them are both reflected in the Team Explorer in Visual Studio. At a higher level, sub-sites can also be created in Sharepoint for providing a customized portal for a subset of team project members. Sub-sites are not reflected into the Team Explorer in Visual Studio.
Process Guidance	The process guidance that exists on the team portal is a set of web pages describing the software development methodology being followed. If a subset of the members of a team project need customized guidance, it can be reflected on the existing process guidance pages, or a new set of pages can be created.
Area and Iteration Classifications	The area and iteration classifications are both hierarchies that can be structured as appropriate to represent the functional and temporal breakdown of your application respectively. As mentioned previously, if you are managing multiple applications in a team project, you’ll likely want the top level of the area hierarchy to reflect the applications being managed. Similarly, if you are representing multiple releases in a team project, you’ll likely want the top level of the iteration hierarchy to reflect the releases.
Security Groups	TFS provides a built-in security group mechanism that allows you to manage group membership in TFS rather than through Active Directory or the operating system. These groups can contain any arbitrary set of windows users, windows groups, or other TFS groups. As such, you can subdivide your team as necessary, define the needed groups to represent those subdivisions, and then create additional groups to aggregate those into larger lists of users.
Check-in Policies	Check-in policies are scoped to all source in a team project. This can make it challenging to manage a large source base in a team project because the policies you wish to define for one part of the source tree may not apply for another part of the source tree. The latest release of the Team Foundation Power Tools:http://go.microsoft.com/?linkid=5422499 provides a check-in policy that can be used to scope other check-in policies to a subset of the source tree for a team project.
Exclusive Check-out	Exclusive checkout in version control can be enabled only at the team project level and not on a subsection of the team project source.

Microsoft Team Foundation Server Branching Guidance

NEW POST: Concurrent Development with single integration line

NEW POST: Blocking branches

NEW POST: Feature Branch Life Cycle

NEW POST: Bugfixing

NEW POST: Real-life scenarios

NEW POST: Feature Branch Life Cycle

NEW POST: When to start feature-branches

UPDATED WIKI: Guidance for Structuring Team Projects

Guidance for Structuring Team Projects

Introduction

What is a Team Project?

Components of a Team Project

Team Project Scalability

Strategies for Employing Team Projects

Strategy 1: Team Project Per Application

Strategy 2: Team Project Per Release

Strategy 3: Team Project Per Team

Providing Substructure Within a Team Project

Other Common Questions

UPDATED WIKI: Guidance for Structuring Team Projects

Guidance for Structuring Team Projects

Introduction

What is a Team Project?

Components of a Team Project

Team Project Scalability

Strategies for Employing Team Projects

Strategy 1: Team Project Per Application

Strategy 2: Team Project Per Release

Strategy 3: Team Project Per Team

Providing Substructure Within a Team Project

Other Common Questions

UPDATED WIKI: Guidance for Structuring Team Projects

Guidance for Structuring Team Projects

Introduction

What is a Team Project?

Components of a Team Project

Team Project Scalability

Strategies for Employing Team Projects

Strategy 1: Team Project Per Application

Strategy 2: Team Project Per Release

Strategy 3: Team Project Per Team

Providing Substructure Within a Team Project

Other Common Questions

UPDATED WIKI: Guidance for Structuring Team Projects

Guidance for Structuring Team Projects

Introduction

What is a Team Project?

Components of a Team Project

Team Project Scalability

Strategies for Employing Team Projects

Strategy 1: Team Project Per Application

Strategy 2: Team Project Per Release

Strategy 3: Team Project Per Team

Providing Substructure Within a Team Project

Other Common Questions