none
Where to Create New TFS Project

    Question

  • I'm looking for some opinions on where to create a new TFS project.  Here's our situation...

     

    We currently support three different projects all of which fall under three separate TFS projects.  This seems to work for us technically.  However, the business side tends to have some issues with it because we have three separate SharePoint portals for storing our design and requirements documentation (as well as other types of documentation).

     

    We're now getting ready to create a fourth projects that is somewhat similar to two of the above projects.  I thought about including our new project within one of the existing TFS projects to avoid creating a fourth SharePoint site.  However, we use continuous integration builds with all of our projects and I didn't know if I wanted to have to continually build every solution with each check-in (i.e. if I check in code for the fourth project, why should I have to rebuild the solution for a pre-existing project).

     

    I checked out the Guidance for Structuring Team Projects but it didn't really seem to cover this scenario.  I'm leaning toward creating yet another Team Project just because this seems to be the easiest solution technically.  However, I'm not totally happy with this solution since I really don't want to create a Team Project for every project our team eventually ends up working on.

     

    Any words of wisdom, advice, experiences, etc.?

    Monday, May 14, 2007 1:15 PM

Answers

  • My personal opinion is to err on the side of keeping the same Team Project.

    However, we use continuous integration builds with all of our projects and I didn't know if I wanted to have to continually build every solution with each check-in (i.e. if I check in code for the fourth project, why should I have to rebuild the solution for a pre-existing project).

    Agreed.  All you should have to do is create a new build type.  That's a lot less overhead than a whole new Team Project.
    Monday, May 14, 2007 8:47 PM
  • I would use seperate team projects because the requirements, PM artifacts, development articfacts, etc, are usually distinct to the project and I like to have seperate document libraries for the distinct development efforts.  However we have encountered a similar situation where we have a program for the redevelopment of several legacy systems where each legacy replacement constitutes a seperate project under the program.

     

    Each one of the projects has its own TFS project and matching SharePoint site.  We then went and created a stand alone SharePoint site to host the program artifacts.  That site holds all of the common content/artifacts (non-sourcecode) and contains links to each of the project sites.

     

    This format is working well for us.

    Wednesday, May 16, 2007 2:56 AM

All replies

  • My personal opinion is to err on the side of keeping the same Team Project.

    However, we use continuous integration builds with all of our projects and I didn't know if I wanted to have to continually build every solution with each check-in (i.e. if I check in code for the fourth project, why should I have to rebuild the solution for a pre-existing project).

    Agreed.  All you should have to do is create a new build type.  That's a lot less overhead than a whole new Team Project.
    Monday, May 14, 2007 8:47 PM
  • I would use seperate team projects because the requirements, PM artifacts, development articfacts, etc, are usually distinct to the project and I like to have seperate document libraries for the distinct development efforts.  However we have encountered a similar situation where we have a program for the redevelopment of several legacy systems where each legacy replacement constitutes a seperate project under the program.

     

    Each one of the projects has its own TFS project and matching SharePoint site.  We then went and created a stand alone SharePoint site to host the program artifacts.  That site holds all of the common content/artifacts (non-sourcecode) and contains links to each of the project sites.

     

    This format is working well for us.

    Wednesday, May 16, 2007 2:56 AM
  • Thanks for all the responses.  We ended up creating a separate Team Project - mainly for these two reasons:

    • It's simpler to implement Continuous Integration in separate Team Projects - the CI build type for each project only has to worry about building the deliverables for that project.
    • It allows us to transfer the project to another development team if that becomes necessary (and sometimes does).

     

    Wednesday, May 16, 2007 11:38 AM