We have just gotten TFS 2010 up and running. We will be migrating our source into TFS but I have a question on how to organize the code.
TFS 2010 has a new concept of project collections so I have decided that different groups within our organization will get their own group. My team develops many different web applications and we have several shared components. We also use a few third party components (such as telerik).
Clearly each web application is it's own project but where do I put the shared components? Should each component be in it's own project with separate builds and work items?
Is there a best practice or recommended way to do this specific to TFS 2010?
Best Answer
The best practice for this is to have everything that you need to build a solution under your Main/Trunk folder. We use the following format:
This keeps all of your branches at the same level so you do not have any doubt as to which is a branch and which is a folder.
That's your Team Project structure, but what about the actual folder structure under each of the branches:
The idea is that it is the team's choice whether to use a new version of an external product or reference library. Just because one team can upgrade to a new version of NUnit does not mean that another team chooses not to as it is weeks of work.
By all means have a central "Tools" project that you always update with the latest and your team pulls from there, but do not have external dependencies. It makes it a nightmare to do automated builds and makes your developers upgrade even if it is not a good time. On top of that make sure you treat any external dependency as a Tool even if it is from another internal team.
References: TFS Deployer