This project has moved. For the latest updates, please go here.

Proper TFS Project, seperate source control and seperate branching Usage Advice

Jan 16, 2013 at 11:00 PM

There was  scenario that I do not see catered for, for projects before TFS, with other tools, we used to follow this method, can you perhaps help me out with some additional guidance.

I have a client, they have several product streams, and some of these products talk to each other, and some parts of some products only exist to supplement a single product, some service several products…

Our Example:

                      SharePoint front end

                      BizTalk Integration Layer

                                              External parties

                      SQL Database project central store, shared.

                      Other internal systems

 

Firstly we run multiple projects at once, with multiple teams.

We have source code for the various systems, they do interact with each other, some not all, and the integration layer between is considered a separate system, as we use an ESB concept where all interfaces are re-usable, as we do often 80% of the time re-use them.

 

We have source code repository for these streams:    

Root

\SharePoint

\BizTalk

\Database(special name)

\Internal system1

\Internal system2

 

Leaving aside from the branches, for main, dev, test and uat, and the whole management of branches for the moment…

 

We will have a project…..

                      It will take branches from SOME, never all of the streams of source code.

 

Here is where it gets interesting…..

 

What we used to do, was make a team project in TFS for the project, because we can use the same source code, and take branches into our new TFS project, we take a branch of main into our TFS project for the Streams in this project.

Two interesting parts:

We may have another project….. That shares some of the same parts not all of the source code for the streams.

We may have another phase of an existing project we want to kick off, usually before the previous one has finished.

 

The guidance indicates a single TFS team project per product, however we have a few products but there are MANY projects that cover some of these products.

Do we create team projects for each of our projects, and then new phase of the same project occur in the same team project and can be identified by a separate branch, and work items with a different area or iteration…..??

 

Our team projects have 30 – 40 releases over a 5 year period, and eventually touch most of the source base of all product streams, loads of work items/stories/bugs, iterations, quite massive..... and I do not want to to be extremely messy... .

We have NEW projects that do not touch SharePoint, and are integration only projects that touch a couple of systems (no code in these systems, or external systems) would these be created as separate TFS projects, and branching of the source code done.?? Is this valid?

My biggest problem with TFS has always been the weird way the source code and the team projects are tied together so tightly…. A project can cover code from lots of projects, do you create a master main team project that’s just for source code storage, and is always branched from, with a main branch and maybe has the release branch.

I would hope someone has come across this before and I’m not alone here…. I’ve documented much of this, and it went along the lines of your branching guide, but took it further…. What I’m looking for is the best practice, as I have a client that has not start down this route already and is NOT willing to fix their mistakes…. They are about to go TFS 2012 and re-structure their entire TFS as they have gone down a totally wrong route.

Can some TFS people please help with the detail so we can get it right, I'll publish the results for all, freely, once its done.

Jan 17, 2013 at 3:07 AM
I don't know what "best practices" are. I'll let someone else speak to that. But the last two places I used TFS, we used one single TFS Project to store all source control for our main products. And we ran all our projects out of that one TFS project. So all work items were comingled in one TFS project. We kept projects separate by using Iterations. Here is an example Iteration tree
-Projects
----2012
----2013
-------Project A
-------Project B

And we used the Area to designate different products.

IMHO, TFS would fit our world better if it could make its source control container more loosely coupled to the work item container, to represent that SOFTWARE PRODUCTS are not PROJECTS. Then we could have one source control container for every major software product. And one project container for every major work effort. Then if you could somehow link a project container to multiple product containers, we could check in changes to various products as part of a single task in the project.




On Wed, Jan 16, 2013 at 5:00 PM, PaulSomers <notifications@codeplex.com> wrote:

From: PaulSomers

There was scenario that I do not see catered for, for projects before TFS, with other tools, we used to follow this method, can you perhaps help me out with some additional guidance.

I have a client, they have several product streams, and some of these products talk to each other, and some parts of some products only exist to supplement a single product, some service several products…

Our Example:

SharePoint front end

BizTalk Integration Layer

External parties

SQL Database project central store, shared.

Other internal systems

Firstly we run multiple projects at once, with multiple teams.

We have source code for the various systems, they do interact with each other, some not all, and the integration layer between is considered a separate system, as we use an ESB concept where all interfaces are re-usable, as we do often 80% of the time re-use them.

We have source code repository for these streams:

Root

\SharePoint

\BizTalk

\Database(special name)

\Internal system1

\Internal system2

Leaving aside from the branches, for main, dev, test and uat, and the whole management of branches for the moment…

We will have a project…..

It will take branches from SOME, never all of the streams of source code.

Here is where it gets interesting…..

What we used to do, was make a team project in TFS for the project, because we can use the same source code, and take branches into our new TFS project, we take a branch of main into our TFS project for the Streams in this project.

Two interesting parts:

We may have another project….. That shares some of the same parts not all of the source code for the streams.

We may have another phase of an existing project we want to kick off, usually before the previous one has finished.

The guidance indicates a single TFS team project per product, however we have a few products but there are MANY projects that cover some of these products.

Do we create team projects for each of our projects, and then new phase of the same project occur in the same team project and can be identified by a separate branch, and work items with a different area or iteration…..??

Our team projects have 30 – 40 releases over a 5 year period, and eventually touch most of the source base of all product streams, loads of work items/stories/bugs, iterations, quite massive..... and I do not want to to be extremely messy... .

We have NEW projects that do not touch SharePoint, and are integration only projects that touch a couple of systems (no code in these systems, or external systems) would these be created as separate TFS projects, and branching of the source code done.?? Is this valid?

My biggest problem with TFS has always been the weird way the source code and the team projects are tied together so tightly…. A project can cover code from lots of projects, do you create a master main team project that’s just for source code storage, and is always branched from, with a main branch and maybe has the release branch.

I would hope someone has come across this before and I’m not alone here…. I’ve documented much of this, and it went along the lines of your branching guide, but took it further…. What I’m looking for is the best practice, as I have a client that has not start down this route already and is NOT willing to fix their mistakes…. They are about to go TFS 2012 and re-structure their entire TFS as they have gone down a totally wrong route.

Can some TFS people please help with the detail so we can get it right, I'll publish the results for all, freely, once its done.

Read the full discussion online.

To add a post to this discussion, reply to this email (vsarbranchingguide@discussions.codeplex.com)

To start a new discussion for this project, email vsarbranchingguide@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
David Kreth Allen
612-374-1119
Coordinator
Jan 17, 2013 at 4:39 AM

A few questions to clarification:

  1. What do you mean with Streams?
    Not sure we are following...
  2. What is your definition of  a project?
    If we use Visual Studio as an analogy, is your project Visual Studio or IntelliTrace, Architecture Tooling, etc.? The definition will help us walk through the planning guide and determine the team project collection and team project structure.
  3. Where in the guidance are we recommending a single Team project per project?
    We do not recommend that and typically recommend less (single) team projects containing multiple products/projects segregated using areas or in TFS 2012 Teams. See http://vsarPlanningGuide.codeplex.com which discusses the team project collection and team project question of one or many. Also see our dogfooding blog series in which we are sharing our objective to consolidate from many to one Team project, our experiences and challenges.
  4. Why does the code sharing guidance in the latest http://vsarbranchingguide.codeplex.com guide not suit you?
  5. Why are you saying that source code is tightly coupled to a team project?
    I need to mull over this and your response, because I feel it is loosely coupled to a team project and tightly coupled to a team project collection.

At this stage I am leaning towards a release or feature branch scenario, using code sharing, a single Team Project and implementing branch when and as needed. Start simple and avoid complexity at all cost ... it is easy to create a complex branching environment, but a nightmare to merge.

Jan 19, 2013 at 3:31 AM
I'm glad you posted this reply. I had a serious misconception that I cleared up. I thought that I had to have all my work initiatives ("Projects" in the business sense) share a single TFS Team Project in order to operate on a shared code base. After reading your message, I did an experiment on TFS 2012 and TFS 2010, and discovered what you already knew: I could create a separate TFS Project for every business project, yet still have source code in one place. Or even go so far as to have a many-to-many relationship between TFS projects with their source code assets and the TFS Projects with work items.

I don't know where I learned that incorrect assumption. Was it a limitation from an earlier version of TFS perhaps? I remember being frustrated long ago because I wanted to create a new TFS project for a new business project, so we could use a different Project Workflow template.

Anyway, I posted it so others who may have my misconception may see the opportunity.

Also, I did not know the "ADVANCED VERSION CONTROL GUIDE" existed. It's a nice resource. Thanks for mentioning it.

On Wed, Jan 16, 2013 at 10:39 PM, wschaub <notifications@codeplex.com> wrote:

From: wschaub

A few questions to clarification:

  1. What do you mean with Streams?
    Not sure we are following...
  2. What is your definition of a project?
    If we use Visual Studio as an analogy, is your project Visual Studio or IntelliTrace, Architecture Tooling, etc.? The definition will help us walk through the planning guide and determine the team project collection and team project structure.
  3. Where in the guidance are we recommending a single Team project per project?
    We do not recommend that and typically recommend less (single) team projects containing multiple products/projects segregated using areas or in TFS 2012 Teams. See http://vsarPlanningGuide.codeplex.com which discusses the team project collection and team project question of one or many. Also see our dogfooding blog series in which we are sharing our objective to consolidate from many to one Team project, our experiences and challenges.
  4. Why does the code sharing guidance in the latest http://vsarbranchingguide.codeplex.com guide not suit you?
  5. Why are you saying that source code is tightly coupled to a team project?
    I need to mull over this and your response, because I feel it is loosely coupled to a team project and tightly coupled to a team project collection.

At this stage I am leaning towards a release or feature branch scenario, using code sharing, a single Team Project and implementing branch when and as needed. Start simple and avoid complexity at all cost ... it is easy to create a complex branching environment, but a nightmare to merge.

Read the full discussion online.

To add a post to this discussion, reply to this email (vsarbranchingguide@discussions.codeplex.com)

To start a new discussion for this project, email vsarbranchingguide@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
David Kreth Allen
612-374-1119