Dylan Smith

ALM / Architecture / TFS

  Home  |   Contact  |   Syndication    |   Login
  72 Posts | 0 Stories | 126 Comments | 29 Trackbacks



Image Galleries

Blogs I Read

I seem to be spending a lot of time lately trying to convince clients that a single Team Project for the entire Enterprise is the way to go.  To most people this seems counter-intuitive.  They tend to create Team Projects for each actual Project and/or Team within their Enterprise.  That just makes sense right?  Indeed, if you look at most books on TFS they will usually have a section with guidance on Scoping Team Projects that usually recommends approaches that result in many Team Projects.  My “go to” TFS book - Professional TFS 2012 - recommends choosing one of 3 approaches: Team Project Per Application, Team Project Per Release, or Team Project Per Team.

However, most TFS experts have come to agreement in the past couple of years that one big Team Project for the entire Company is often the best choice.  The fact that this realization is relatively new explains why you won’t find much literature on it in published TFS books (hopefully that will change in the near future).  Within the group of ALM MVP’s (which includes most people who would be considered TFS experts) most of us agree on this approach.  And in fact most (all?) of the Microsoft TFS Product Team that I’ve talked to about this agree with the Single Team Project approach (they use this approach internally within Microsoft).  Microsoft is actively introducing new TFS features that make this approach easier (more on that below). I also had a conversation with the authors of the Professional TFS 2012 book recently, and they all agreed that their guidance is outdated, and the next edition of that book should focus more on the Single Team Project approach.

The best source of information I’ve found to date on this topic is a handful of blog posts by Martin Hinshelwood (in chronological order):


What’s Wrong With Many Team Projects

The core of the problem is that introducing multiple Team Projects introduces constraints and limitations on what you can do, while providing little benefits.  The perceived benefits of multiple Team Projects can usually be realized within a Single Team Project just through different mechanisms, and without the limitations that Team Project boundaries place on you.

What are the reasons that teams typically create multiple Team Projects?  They do so because there are benefits to isolating and separating the various assets of each project/team, and creating a Team Project for each seems like the most intuitive way to achieve this.  If you have two separate projects (by projects here I mean separate Business Projects typically with different teams working on them), then you typically don’t want members of Project A seeing or being able to modify the assets of Project B (by assets, I mean source code, Work Items, build definitions, etc).  In addition to having security around the assets of each team, you also don’t want to have things like Reports, Backlogs, Queries, etc. showing assets from multiple projects.  Each team should have it’s own separate backlog, reports, etc.  And having a Team Project for each seems like an obvious way to achieve this.

However, the multiple Team Projects can cause significant hurdles if you ever wish to move data across a Team Project boundary.  Team Projects are intended to isolate the data stored in each one, and there is no easy way to move some data from one Team Project to another.  For source code, you could easily grab a copy of the source code in one project, and check-it in to another team project.  However you would lose all history.  I think you might be able to also do a Move command to move source code from one project to another, but again the History doesn’t come across (at least not in an ideal way).  You can try to use the TFS Integration Platform (TIP) to migrate source code and history, however the TIP is horribly buggy and awkward to use.  So much so that most TFS Experts I know refuse to even try to use it anymore.

The real problems though come when talking about Work Items.  There is no obvious way to move Work Items between projects.  Again, you might think the TIP is an option, but just like with source code, the TIP is crippled to the point of being unusable.  Excel is a popular choice, export the WI’s from one Team Project into Excel, then use Excel to Import them into the other Team Project.  There are some major issues with the Excel approach:

  • Any HTML fields (such as most description fields) will lose all formatting when being exported to Excel.  This is usually unacceptable.


  • If the Work Item Type Definitions between projects differ then you may be in trouble.  At a minimum you will have to go through a mapping exercise to determine how the Work Item Types and fields from one project map to fields in the other project.  Then apply that mapping manually via Excel as part of the Export/Import process.


  • Most WI’s only have one valid “starting state”, then defined transitions from that state.  So lets say your WI workflow enforces all WI’s start in “New”, then they must go to “Approved”, then finally to “Done”.  Well how do you migrate WI’s that are already in the Done state?  You can’t just Excel-Import them, because you’d effectively be trying to create a new WI directly into the Done state, which isn’t allowed.  You’d have to first import them all as New, then transition them to Approved, then to Done.


  • You will lose WI History.  This is often acceptable for most teams, but thought I’d point it out anyways.


To summarize, moving data (specifically WI’s) between Team Projects is complex and extremely time-consuming.  It can be done, but usually requires you to hire a TFS Consultant to help you with it, and that can get very expensive.  As a TFS consultant myself, you might think I’d be happy about this.  After all, my company makes a lot of money helping clients with things like this.  But believe me when I tell you, if I never have to do a WI migration ever again, I will be a happy guy.


There is still one last important point here to bring this all together, why would you ever want to move data between Team Projects?  If you specifically created a Team Project for each project/team, then you should never need to move data between them right?  Wrong!  There are a number of reasons why the Team Project structure you create initially may not be appropriate 5 years from now.  Here’s some examples of situations I’ve run into with clients:

  • One team starts a project, then gets handed off to a different team later
    • A common example is where one team will develop some software, then hand it off to a different team for support/maintenance.  That maintenance team is often responsible for many projects.  The maintenance team wants all their work items for all their projects in one team project so they can see one “team backlog”, and roll-up reports across projects.  They also may want to see backlog/reports for each specific project under them also.


  • You have a single Team that works on multiple Projects
    • An example I’ve seen is you have 4 projects each in their own Team Project, but you have a shared BI team that handles all reporting/ETL/Data Warehouse tasks across all projects.  Each project wants to see all of the project tasks together, and the BI team wants to see a consolidated list of work/backlog that belongs to the BI team.  If each of the 4 projects have their own Team Project, then there is no way for the BI team to see a consolidated backlog of their work.  If you create a separate Team Project for the BI team then there’s no easy way to move BI work items into that project, and if you duplicate them you run into another set of problems.

One last point that is useful to keep in mind, is that in general it is easier to split a team project up into multiple Team Projects later, than it is to start with many and combine them. 


Structuring the Single Team Project

Going with a Single Team Project avoids most of the above problems.  You will obviously never need to move Work Items (or code) between projects.  But now you have the challenge of how to organize data within the Single Team Project to provide separation and isolation.  This is accomplished mostly through a combination of using the Area hierarchy and Teams functionality.  If we imagine we combine what used to be multiple Team Projects into a single team project, we end up with many “sub-projects” (not an official term) within the single Team Project.  We can create a root Area for each sub-project, a TFS Team for each sub-project, and a root source control folder for each sub-project.  Then we can use the Area field to filter all reports and queries.  Each Team is tied to the related Area and is used to provide each Team/Sub-Project with it’s own Product Backlog.  And Security can be granted based on Area and/or Source Control Path. 



You should create a root area for each sub-project.



Just like with Area hierarchy you should create a root node in the Iteration Hierarchy for each sub-project.  Then you can maintain/manage the sprints/iterations for each sub-project separately.  


Source Control 

Create a root folder for each sub-project.


TFS Teams 

Create a TFS Team for each sub-project.  You can create a hierarchy of Teams, so each sub-project could potentially have many teams each with their own Product Backlog, then then roll-up into the parent team for that sub-project.


TFS Security Groups 

You probably don’t want to use the default TFS Security Groups (Reader, Contributor, Build Administrator, Project Administrator).  If you give somebody the Contributor role, it will make them a Contributor across every sub-project which probably isn’t desired.  What you should do is create those 4 groups for each and every sub-project.  So if you have 5 sub-projects, you should end up with 20 TFS Security Groups (plus the original 4 that aren’t sub-project specific).


Work Item Security 

Grant the various sub-project Security Groups permissions for the root Area associated with that sub-project.  This will ensure that only members of that team can edit/view WI's that belong to that teams' Area(s).


Source Control Security 

Just like Work Items, you should grant the sub-project Security Groups permissions only to the root folder associated with that sub-project.


Build Agents/Controllers 

Ideally you would have a Build Controller for each sub-project, then one or more Build Agents/Build Servers for each sub-project.  Having separate build-agents/build-servers for each sub-project has long been a good practice.  This is because a team typically needs admin rights on their build server, and often need to install various software/SDK’s/frameworks/etc. onto the build server to support their build process.  This is different for each team typically, so you usually don’t want to share build servers between teams.  The separate build controller recommendation is to avoid the possibility of a team accidentally using another team’s build server.  If we were to share a Build Controller, it is too easy to accidentally configure the build to use any build agent regardless of “agent tags”, but this will have the unintended behavior of using other teams/sub-projects build servers/agents.  By forcing me to pick a sub-project specific build controller when setting up a build definition, this makes it harder to accidentally run into this situation.


Build Definitions 

When you have a Single Team Project, you are going to end up with a very long list of Build Definitions since all sub-projects Build Definitions will all be mashed together into one list.  In 2010 there used to be a tool called InMeta Build Explorer that would allow you to introduce virtual folders to organize them.  That tool does not work in TFS 2012/2013, however there are new features built into TFS/VS that make things more manageable. You can now filter/search through the Build Definition list right in Team Explorer, you can also setup My Favorites and Team Favorites to make your most common builds more visible.


Work Item Queries 

You can create folders to organize Work Item Queries.  You should create a root folder for each sub-project, then assign permissions appropriately so each sub-project Security Group only has permission to it’s relevant WIQ folder.


SharePoint Portal

If your team uses a SharePoint Project Portal then you will ideally want a separate Portal for each sub-project that only shows data for that sub-project.  You can accomplish this by opening up the main Portal (for the Team Project) then create a new SubSite for each sub-project.  When you create the SubSite pick the TFS Project Portal Site Template.  Then open up the new Portal and you will need to edit each Web Part properties to ensure they all filter by the relevant Area for this sub-project.



For the Reporting component of TFS no changes are needed.  Most (all?) Reports include the ability to filter by Area, so you simply filter by the Area corresponding to the Sub-Project you are interested in.


What’s The Downsides to a Single Team Project

There are a couple downsides to doing the Single Team Project approach:


More Complex Administration 

Adding a new sub-project requires a little leg-work to setup the proper security groups, root areas, WIQ folders, etc.  You generally need to have a central TFS Administrator group/person that understands this process (and probably has it documented) and performs it whenever a new sub-project is needed.  For example creating a new sub-project might consist of the following steps:

  • Create root Area
  • Create TFS Team
  • Create WI Query Folder
  • Create root Source Control folder
  • Create Team-specific Security Groups
  • Setup Build Controller/Agent
  • etc


Process Template Customizations 

Any customizations to the Process Template or Work Item Type Definitions will apply to every sub-project.  This is by far the biggest problem.  Any custom fields, or custom WI workflow states, or even custom WI Types will show up in all sub-projects.  Microsoft appears to be rapidly introducing features that help mitigate this problem.  Some examples of ways to mitigate this could be:

  • Ensure all changes go through a central TFS Administration group.  This group can try to minimize customizations by suggesting alternatives (ex. adding a transition reason rather than an entirely new state).  Also you can try to make then more generic (e.g. Adding a custom field to link to a bug in HP QC, you could call it Quality Center ID, or you could call it Reference ID then it can be used across other sub-projects to link to other external systems that maybe aren’t QC).


  • Work Item tags allow you to input metadata against a Work Item without needing to customize the WITD.  This is *great* for the Single Team Project approach, because you can now enter sub-project specific information without needing to add customizations that affect other sub-projects.  For example, if one sub-project really wants to designate some Bugs as HotFix, they might try to add a custom-field “HotFix?” with a Yes/No dropdown.  The problem is, that HotFix dropdown will show up on all sub-projects, and other sub-projects probably would have no idea what that even means.  Instead you could simply apply a HotFix tag to those WI’s in that specific sub-project only.  Another example, is only a small number of sub-projects want to put a Priority field on Tasks (High, Medium, Low).  Instead of a custom field they could simply use tags: “Priority: High”, “Priority: Medium”, “Priority: Low”.


  • Kanban Boards introduced into TFS recently allow you to define different Kanban states/workflows for each Team.  This can often allow you to keep the Workflow states very generic just to support cross-project reporting.  Then the team-specific Kanban states can be used to model each teams specific workflow.


  • Work Item Extensions is a new feature introduced to enable the KanBan Boards.  It is not currently possible for anybody other than Microsoft to take advantage of this feature, but the TFS Team used Work Item Extensions to implement the KanBan features.  It adds custom fields to WI’s dynamically based on the Area Path of the WI.  In theory (and this is my hope), as this feature evolves it will allow us to define custom fields that only apply to a specific Area associated with a specific sub-project.
posted on Thursday, September 5, 2013 5:54 AM


# re: Single TFS Team Project 9/5/2013 11:41 AM Martin Hinshelwood
I would suggest that the TFS Integration Tools are not nearly as scary if you get an expert (one of those MVP's) to run them for you. While still a very painful process for older code repositories, for work items it can be trivial to push them around as long as the process templates match on either side first...

# re: Single TFS Team Project 9/6/2013 3:42 AM David Gannon
With one team project, does the backlog planning / board tools work with multiple crossing sprints?

For example, Project 1/Release 3/Sprint 1 is Sept 3 - 13 and Project 2/Release 1/Sprint 2 is Sept 9 - 20th. How will the burndown reports / planning tools and progress board react?

# re: Single TFS Team Project 9/6/2013 3:49 AM Dylan Smith
Good catch David. Iteration Hierarchy can have root nodes for each sub-project/team just like the Area Hierarchy. So each team can have it's own set of sprints/releases with different independent date ranges.

Burndown/backlogs/boards are all team specific. So whichever team context you are in, you would pick the appropriate sprint for that team when trying to view the taskboard or burndowns.

Note: I updated the post to include a blurb on iterations.

# re: Why You Should use a Single (Giant) TFS Team Project 9/6/2013 7:48 AM Jeroen Vos
I could think of a few more downsides:
- No easy linking of Sharepoint portals. Creating a subproject would be a nightmare if you needed a sharepoint portal with it, including dashboards.
- There is no way for different teams to use different process templates.
- Report server reports are a bit harder to maintain for each subproject I guess.

# re: Why You Should use a Single (Giant) TFS Team Project 9/6/2013 8:38 AM Dylan Smith
@Jereon For Process Templates I covered that in the last section of my post. Definitely the biggest downside, but something that can be mitigated today, and I expect will become even less of an issue going forward as MS introduces more functionality (e.g. WI Extensions).

For Reporting most (all?) Reports include the ability to filter by Area, which allows you to leave the default reports in tact and simply filter for the Area that corresponds to your sub-project.

SharePoint is a good question. There are things you can do if the SharePoint Portal is important to you. You can create a SP SubSite for each sub-project, and use the TFS Project Portal template, which will create a new Portal for each Sub-Project. After you create a SubSite you need to edit the properties for every WebPart to filter by the Area that corresponds to this SubProject.

Note: I'm about to update the blog post to include a blurb on SharePoint.

# re: Why You Should use a Single (Giant) TFS Team Project 10/17/2013 5:08 PM Ramesh
I have tried one Project for WorkTracking (Work Items, Areas per application, teams, One common iteration path) , and individual team projects for each Application. Modified the My Queries of each team project to list the WorkTracking Work items. The Individual projects gives the app team flexibility to manage code and permissions seperately. Seems to be working fine so far..

# re: Why You Should use a Single (Giant) TFS Team Project 10/20/2013 2:39 PM John Hughes
Creating a subsite in SharePoint with the TFS Project Template does not include the dashboard page nor the Shared Documents library or any web parts. You just get an empty site... I believe the link to the Process Guidance and a calendar are all you get.

# re: Why You Should use a Single (Giant) TFS Team Project 11/11/2013 12:06 AM Rich
Agreed. The shared assemblies aspect and QA test cases means a single big project works best for us.

# re: Why You Should use a Single (Giant) TFS Team Project 11/13/2013 3:19 AM Patrick Magee
I agree with Martin - I have used TIP for years to move WIs between projects. However, the pros of a single giant project do outweigh the cons. The worst is that the Sharepoint integration really is a headache with a single project - to the point I prefer to ditch it altogether, rather than spend weeks editing convoluted SP config. Editing Webparts will sort out your reporting, but it won't help you with the dozens of deeply embedded links to the root of your project.

# re: Why You Should use a Single (Giant) TFS Team Project 12/3/2013 11:58 AM Gary
We are investigating both multiple team projects and single. For multiple, our shared assemblies from one team project are shared with other projects via work-spaces and mappings. This seems to work OK (so far during investigations). So, I think the only downside for us is the lack of cross-project WIs. Copying WIs from project-to-project doesn't sound good.

# re: Why You Should use a Single (Giant) TFS Team Project 12/12/2013 9:21 AM Dylan Smith
@Gary - For shared assemblies, it is better to check-in the binaries to each project to decouple them from the latest version. Even better is to use a Package Manager like NuGet to publish them rather than mapping workspaces. See this post for a little more info: http://geekswithblogs.net/Optikal/archive/2013/01/27/151951.aspx

# re: Why You Should use a Single (Giant) TFS Team Project 1/7/2014 3:23 PM David
Trying to implement this but stuck on permissions, which you skim over. How do I grant permissions to a particular area for a particular group? I am using VS Online.

# re: Why You Should use a Single (Giant) TFS Team Project 1/7/2014 4:28 PM David
Cancel my last. But... another downside of the single project appears to be managing the iterations. Iterations cannot overlap in time, so time features cannot be used.

# re: Why You Should use a Single (Giant) TFS Team Project 1/7/2014 6:03 PM David
One more question. Is it possible to assign an iteration to an area so it becomes invisible to those without permissions for that area. Without this, any user can see all iterations and can even assign work items to other iterations which could cause confusion.

# re: Why You Should use a Single (Giant) TFS Team Project 1/23/2014 12:45 PM Al
As much as I can see some benefits in this approach with regard to team workflow, i.e. the front end team (or any team) can see all of their work items across all projects together, you hit the nail on the head regarding process. I develop many projects for many clients and they absolutely can not share the same process methodology (template). The client always has a say in the process used as ultimately they are paying for it! I do see the benefits of common access to and visibility of SCM resources across a development organization, but I think the 'single team project' approach is just not practical in the real world, and the real solution is that the TFS platform itself needs to be further developed in order to accommodate a more orthogonal workflow.

# re: Why You Should use a Single (Giant) TFS Team Project 3/10/2014 11:34 PM Pillasaar
Most plugins that imports WI from/to microsoft word can only go down to team project as the lowest level. They can't see areas. This means, for example, when requirements WI are imported to word, it will import all of the requirements from all of the projects if we have one team project with all the projects.
There are similar issues with incremental code churn as well.

# re: Why You Should use a Single (Giant) TFS Team Project 3/11/2014 12:30 AM Deniz
Is there a way to use multiple team projects but have sub-projects/teams in some of them ?

We are an industrial automation company which develops both software and hardware products (they use altium and solidworks) and has an independent automation projects team. We want to track all of those projects in TFS and to do that we need to first have a main project branch which will then have the sub-projects for the automation and hardware teams. Our software teams already work with multiple team projects. I don't want to re-install everything from scratch just to support such an infrastructure, so I'm just going to add the hardware and automation team main branches to the already inplace structure.

Is there a way to accomplish what I'm describing here ?

# re: Why You Should use a Single (Giant) TFS Team Project 3/14/2014 3:59 AM Mark
Seems like one other possible downside to this approach is the archiving process. As your project data gets bloated over time you will find that you cannot employ the recommended archiving approach as described http://msdn.microsoft.com/en-us/magazine/gg983486.aspx. Any suggestions on how to pear down the data over time if you only have the one team project?

# re: Why You Should use a Single (Giant) TFS Team Project 3/19/2014 2:38 PM Mark
Thank you for posting this, very very helpfull. You have just solved a burning problem I have had for a while . Moving from 2010 - 2013 and will take your advice.

# re: Why You Should use a Single (Giant) TFS Team Project 3/24/2014 9:17 AM Dylan Smith
@Mark - The only activities I typically do is run the Test Attachment Cleaner to clean out old test data. Other than that I just let it grow, and don't do any archiving activities. Are you finding that your TFS database size is causing you problems? I have yet to run into that.

# re: Why You Should use a Single (Giant) TFS Team Project 3/31/2014 11:42 AM Mark
@Dylan - I personally have not yet run into a problem with our Team Server size internally, but am consulting with a major State Agency in Oregon that is employing TFS and will be housing a few hundred applications eventually, and I can see 5-10 years down the line there being a problem if they have no way of permanently removing some of the older source versions/applications/work items that no longer matter. Perhaps by then there will be easier ways of migrating data piecemeal to solve this issue.

# re: Why You Should use a Single (Giant) TFS Team Project 5/7/2014 7:39 AM Del
@David - back in Jan you asked about permissions but then backtracked on it - did you find your answer somewhere? I have the same issues specific to Source Control.

@Dylan - I created the "sub-area" specific copies of the Security roles but am having issues with the new "sub-area" roles not being able to do what the default roles do, like create Builds, edit Build definitions and Clone builds. I have set up the "sub-area" Build Admin and Project Admin with the same permissions (as far as I can see) as the default Build Admin and Project Admin but users assigned to the sub-area roles can't do the same things as the users that are assigned to default roles - help?

# re: Why You Should use a Single (Giant) TFS Team Project 5/9/2014 10:33 AM J
No one is concerned about having a 2TB repo and the "all the eggs in one basket" in regarding to disaster recovery and backup duration?

# re: Why You Should use a Single (Giant) TFS Team Project 5/13/2014 6:58 AM Darren
One of the major pros for this approach, IMO, is the portfolio management aspects. One central team who has visibility over all product backlogs is a huge win, especially for a product owner who may oversee multiple projects (all under 1 "product") which were classically partitioned across 2 TFS projects. When it comes time for the product owner to prioritize the "product" backlog, he/she could do that in 1 place.

# re: Why You Should use a Single (Giant) TFS Team Project 5/15/2014 11:32 AM Dylan Smith
@Del Permissions for builds is a little awkward in this approach because there is no ability to create folders to organize the various build definitions then apply security to the folders (like you would do for WI Queries lets say).

Instead you would typically grant the sub-area-build-admin group permissions across all builds (by modifying the permissions on the All Build Definitions node) then they will be inherited into each individual build definition. If a sub-area team wishes to restrict access to their build defs to only their team, then they will have to modify the permissions on each build def individually.

# one more limitation for this solution 5/22/2014 9:37 AM ran
we ran into a roadblock when we use one team project solution. since our requirement is each team can only see their own code, we apply security to each team folders without giving permission on team project level. However, Labels are defined on team project level. developers can't apply labels and read labels without team project permission. This structure doesn't support separation of security. what's the solution for that?

# re: Why You Should use a Single (Giant) TFS Team Project 5/23/2014 9:10 AM Dylan Smith
@ran That's not the first time I've heard that. My suggestion is don't use labels. I use branches instead of labels. The advantage is you have more control over security (which solves your problem), you also have auditability. Labels are not immutable, meaning that somebody can change a label after it was created, and there is no audit trail that that happened.

# re: Why You Should use a Single (Giant) TFS Team Project 6/10/2014 12:59 PM Cash Foley
For shared assemblies you should set up NuGet server. This is a 'publishing' problem that is always made worse by putting the build output into source control.

# re: Why You Should use a Single (Giant) TFS Team Project 6/26/2014 1:00 AM Steve Davey
Hi, I am experimenting with the single team project approach and I seem to be running into an issue with the burndowns in the SQL reporting server. Using TFS 2012 and the scrum template, having to use the reporting server burndown to remove weekends when I access this for any of the child team projects the burndown is only ever loading for one of the teams and all the other teams also get that teams burndown, has anyone else encountered this and is there a fix?


# re: Why You Should use a Single (Giant) TFS Team Project 6/26/2014 2:05 AM Steve Davey
another question is do you have steps on how to create the security groups by team as mentioned in the post?

# re: Why You Should use a Single (Giant) TFS Team Project 6/27/2014 8:24 AM Dylan Smith
@Steve When you run the burndown report you have to select the area that corresponds to the team, and also the team specific iteration. Are you doing that? To be honest I don't use the SSRS reports that much, the burndown in web access meets my needs (in 2013.2 they fixed the weekend problem).

I don't have any detailed instructions on creating the security groups, but you just need to fire up the web-admin interface, go to the Security Tab, and start creating TFS Groups. Give the TeamA-Contributor the same base rights as the global Contributor from the Security tab. Then you need to go out and assign the team-specific groups permissions in a few different places: Version Control, Areas, Iteration, WI Queries, etc

At some point I plan to post a more detailed blog entry with detailed instructions (screenshots, maybe a video). But my blogging tends to come in spurts, so it's just a matter of finding time and motivation.

# re: Why You Should use a Single (Giant) TFS Team Project 7/7/2014 3:26 AM Steve Davey
@Dylan thanks for the reply, I will have a look at how the SQL server burn down can be amended, we are using the 2012 version currently so need to use this report to remove weakened.

Be good to read the blog around security permissions when you find the time.

Have you noticed any performance issues housing all of your code bases in one single team project? we run lots of applications and wondered if this may encounter issues with build performance.

# re: Why You Should use a Single (Giant) TFS Team Project 7/16/2014 2:57 AM Dylan Smith
@Steve I've never seen any performance issues due to single team project. TFS can handle quite a lot more users than most companies have with little effort (just look at the numbers in the install guide). And whether you have 500 users spread across 5 team projects, or 1, the TFS Server basically handles the same load. For build performance you just keep throwing more build servers at it so you can run more concurrent builds.

# re: Why You Should use a Single (Giant) TFS Team Project 8/19/2014 4:54 AM DaveK
I have set up a single project for our division and it is going well except for the MTM integration. I would like to see the capability to use folders in the Testing Center when I select a project. These folders should also have security settings.

# re: Why You Should use a Single (Giant) TFS Team Project 8/27/2014 6:32 AM Dylan Smith
@DaveK Do you mean folders to hold the Test Plans? I agree this would be nice. I usually use a prefix on my Test Plan names for each team. Typically there are not a lot of Active test plans at any given time, so it's never been too much of an issue for me. You might try assigning the Areas properly for each Plan, then use security/permissions at the Area level. I haven't tried this, but it might only show the plans which you have access to based on Area, so that would solve the problem.

# re: Why You Should use a Single (Giant) TFS Team Project 9/11/2014 9:34 AM Ed
Dylan: Would appreciate your thoughts if you've had a chance to check out the enhancements in TFS 2013 Update 3 to see if any of the changes help simplify or support setting up a Single TFS Team project. I'm new to TFS and I'm just getting started with implementing this approach. Since your original post is a year old I wondered how much might have changed and what insights you might add. Also, can you recommend any good articles on understanding "Area"? Thanks, Ed

# re: Why You Should use a Single (Giant) TFS Team Project 1/12/2015 11:05 PM Bertrand
I have questions about this subject : The real problems though come when talking about Work Items.
>>> Is moving WIs from one project to other, frequent operation ?

- if moving WIs from one project to other is frequent operation, single team project seems to be the solution. But why WI are not initially in the right project ? May be there is upper process trouble which have to be adressed ? Can't these reasons adressed before ?
- if moving WIs from one project to other is not frequent operation, html trouble, field and workflow difference, history (link to source WI) may be done manually.

So fundamental question is : why WIs transferts are frequent and can we adress this problem ?

# re: Why You Should use a Single (Giant) TFS Team Project 3/17/2015 2:00 AM Ankit Doshi
Hi Dylan,

I was trying to follow your blog and trying to setup a single team project for my organisation but i have come across a hurdle.We are using TFS 2013 update 4. As mention by you had create different security group at project level,area level and iteration level and provided the access to appropriate group at appropriate level. My issue is if a user has a project admin role for a team project A and he has access to Area level node of project A when he tries to create a user story and in area path is provided for project A but in iteration path it provide project B iteration path it still allows to do this which should not be the case. I believe this would allow any users of Team project A to add the workitem with iteration path set for Team project B. I was trying to look at the security permission at iteration level and i cannot see any permission which can restrict other iteration path users to do this. This can become a potential flaw of the single team project model. Can you suggest how can i overcome this problem if there is any way.

# re: Why You Should use a Single (Giant) TFS Team Project 3/19/2015 5:35 AM Dylan Smith
@Ankit you shouldn't be making users Project Admins unless you explicitly want to allow them access to all teams/areas/iterations (which it sounds like you don't).

# re: Why You Should use a Single (Giant) TFS Team Project 3/25/2015 2:05 AM Semanur Konezoglu
I came across your blog to understand the current situation of us. We have a giant single project in TFS which causes us to checkout whole branch to add a feature. This project has many solutions and any change in one solution impacts others in production. It is a mess.

# re: Why You Should use a Single (Giant) TFS Team Project 3/25/2015 10:36 PM P. McB.
I'm only starting out on the TFS path but this feels like putting square pegs into round holes. At the beginning of the post we have the point that,
"... there are benefits to isolating and separating the various assets of each project/team, and creating a Team Project for each seems like the most intuitive way to achieve this"

which is true - it is intuitive. But all the reasons for not following the intuitive approach are based on restrictions in the tool. We, as developers of software, strive to make our products intuitive for our users so this leads me to think that TFS is a flawed product. I feel this article is written as though it's a guide to help people follow best practice but the reality is that it's describing a big "work-around" to a problem that shouldn't exist.
As I said, I'm only starting out on this road so I'm prepared to be corrected!

Post A Comment