What is the best project structure and merge flow for TFS?

James Hanley's picture
James Hanley asked on October 23, 2014 - 10:14am | Replies (1).

I'm have promarily used Subversion in the past, and the structure we used was:

/branches    - Self evident name for branch management

   /int          - Integration branches

      /projectA_effort_q4_2014 - Integration branch for release on q4 of 2014

   /usr         - Individual engineers branches

      /fred    - Fred's set of branches

         /some_bug - Fred's branched from somewhere to fix some bug

      /sally    - Sally's set of branches

         /some_feature - Sally's branched from somewhere to add some feature

/tags          - Self evident name for tagging

   /projectA_v1.0 - Tag of projectA at version 1.0

/trunk         - Trunk for various projects

   /projectA  - ProjectA

   /projectB  - ProjectB

/vendor      - Repo path for storing pristine drops of 3rd party code used in various projects

   /acme     - Vendor name of a 3rd party source of code

      /superLib - Acme provides us the superLib

         /current - Latest drop of superLib

         /v1.0_drop - Tagged drop of superLib

         /v1.1_drop - Tagged drop of superLib

 

The machanics of this is to allow for segregated development with maximum traceablity. For example any propriatary changes specific to a project needed within superLib would happen within that project, and only the pristine changes from the vendor would be within the /vendor area, then merged into the project to minimise merge errors.  Users brnach off the integration branches to their own staging areas in usr to integrate new functionality of fix issues and merge them back into the integration branches once proven.  The CM, PM, EM, and PVM would be responcible for merging the integration branch to the trunk project and tagging the trunk project versions.

 

Our current system is TFS based, and is really porrly managed - it was a historical conversion from ClearCase to TFS and there is no clear deliniation as described above.  In fact, it's more like a shot gun of tags and branches, without a really good organzation of where the root of changes should reside, and there's multiple code forks even though 90% of the code is shared.
I was looking to see if it makes sence to refactor the release structure into something like the above, but I'm not sure if it makes sense for TFS and the documentation I can find on TFS doesn't really describe best practices or typical work flows, and the rest of the users here are actually more familier with ClearCase as TFS was a corporate edict of standardization that was pushed onto them.
If you are familier with a better flow or best practice for TFS, please share as our current structure is unmaintainable and unscallable for validation and test purposes.

Thanks much,

-J

1 Answer

Bob Aiello's picture
Bob Aiello replied on November 7, 2014 - 4:10pm.

James,
TFS comes with a number of very good workflow templates straight out of the box. The Agile template is pretty popular http://msdn.microsoft.com/en-us/library/dd997897.aspx
While it is very tempting to customize the templates - I always try to stick with what I get straight out of the box whenever possible.

Bob Aiello, Technical Editor

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.