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…
SharePoint front end
BizTalk Integration Layer
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
We have source code repository for these streams:
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.