This project has moved and is read-only. For the latest updates, please go here.


TFS Branching Guide - Scenarios 2.0 - Missing Content


On page 11, there are Branch definitions for 'Production' and 'VNext' but these definitions are not shown in Figure 8. In the scenario walkthrough on page 13, it would be very useful to understand how the reverse integrations from 'Dev' and 'Dev-1' are handled in Main (specifically when it comes time to release 'Dev' to Production and Main contains changes from 'Dev' and 'Dev-1', what is your strategy to only release 'Dev' changes and not 'Dev-1' changes... Are you using Labels?).
Closed Nov 30, 2013 at 3:59 PM by mikeFourie


wheys wrote Aug 12, 2010 at 9:50 PM

One of my goals for the next release of the guidance is to clean up some of the inconsistencies in our various documents. I appreciate your input to this.
During the development of the original Rangers Branching Guidance II, many people were contributing to this effort. As a result, some of the scenario approaches are somewhat different from the main guidance. These differences are sometimes minor, but also sometimes annoying (to me). I want to rewrite the scenarios so these discrepancies are resolved (or less evident)

With respect to you question of Dev, Dev-1, and Main. I have the following suggestion. Look for this to be a scenario in the next release!
Our guidance is generally to have feature team branches (Dev, Dev-1) be full children of Main. My question would be, whey would both Dev and Dev-1 be merged (RI) to Main if they are not being released together? If Dev is being released, but Dev-1 is in a future release why not merge (RI) just Dev to Main until it is released. Following this, the next time Main is merged (FI) to Dev-1 the Dev feature and Dev-1 features will be integrated in the Dev-1 branch only (not in Dev or Main).
Later, when Dev-1 is ready for release, it can me merged (RI) to Main, stabilized, and then released.
With respect to labels, I tend to use branches rather than labels to provide isolation. Labels are a useful way of tagging a branch as of a point in time or at the point of a milestone. I am not sure how the label helps to keep Dev and Dev-1 separate (isolated).
Does this satisfy your needs?
Bill Heys
VS ALM Ranger

DaveComfort wrote Aug 13, 2010 at 1:48 PM

Thanks for the reply. I agree with your merging approach from the development branches back to Main. The dev teams will need to spend time to make sure the forward integrations from Main do not destabilize 'their' branch (this should be taken care of if the team has created tests to verify their branch). As far as labels go it seems to make sense to label the Main branch each time the software is released to Production. This provides a convenient marker for future branches.
Dave Comfort

wrote Feb 22, 2013 at 1:42 AM

wrote Nov 30, 2013 at 3:59 PM