Microsoft recently published guidance for branching and merging with Team Foundation Source Control. Branching/merging can be a major headache if not thoughtfully planned and managed. However, it is a valuable and necessary tool for parallel development activities. Examples from Microsoft:
Example 1: A team of 40 developers is building an application. There are four feature teams, each led by a development lead. The feature teams vary in size from two developers to fifteen developers. The milestones for each feature area also vary. There needs to be a mechanism to provide isolation to each of the feature teams while allowing for changes to the common areas of the application in a reliable and controlled fashion. Branching is a very good solution here; this is referred to in this document as Branching for Feature Team Isolation. Example 2: A development team has just gone live with the first release of a Web site. The development team has started working on the next version of the site, but a critical bug is found by an important customer on the live site. A strategy needs to be introduced to allow the core development team to continue evolving the next version of the site while bug fixes can be made for maintenance of the released site. There needs to be a mechanism to isolate these two work streams. This is referred to in this document as Branching for Maintenance.
Example 1: A team of 40 developers is building an application. There are four feature teams, each led by a development lead. The feature teams vary in size from two developers to fifteen developers. The milestones for each feature area also vary. There needs to be a mechanism to provide isolation to each of the feature teams while allowing for changes to the common areas of the application in a reliable and controlled fashion. Branching is a very good solution here; this is referred to in this document as Branching for Feature Team Isolation.
Example 2: A development team has just gone live with the first release of a Web site. The development team has started working on the next version of the site, but a critical bug is found by an important customer on the live site. A strategy needs to be introduced to allow the core development team to continue evolving the next version of the site while bug fixes can be made for maintenance of the released site. There needs to be a mechanism to isolate these two work streams. This is referred to in this document as Branching for Maintenance.
You can read the guidance online, or download a PDF version.
Be the first to rate this post
Tags: tfs
Process / Methodology | Tools / Services
4/12/2007 3:05:51 PM #
Troy, this branching is pretty useful and well used feature in Rational rose, we used a lot in our verizon's advanced product division - iobi, where we had to keep on fixing bugs to the live site, while version 2 is under dev. Rational is forerunner for most of the source code control features
Rvel
I'm an Internet technology business strategist, software architect, and development leader specializing in interactive marketing and social media. read more...