Also don't forget Chris Birmele's branching primer: http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx Mitch's TechEd talk from last year: http://notgartner.wordpress.com/2006/08/12/dev303-concurrent-development-with-branching-in-team-foundation-server/ Michael Ruminer's recommendations: http://manicprogrammer.com/cs/blogs/michaelruminer/archive/2006/09/07/88.aspx
Regards, Grant Holliday Readify | IT Manager M: +61 402 414 446 | C: [EMAIL PROTECTED]<sip:[EMAIL PROTECTED]> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grant Holliday Sent: Tuesday, 3 July 2007 11:17 PM To: [email protected] Subject: [OzTFS] RE: TFS branching strategy to support releases [SEC=UNCLASSIFIED] Hi Daniel, I assume that you've read through this guidance? http://www.codeplex.com/BranchingGuidance Do any of these scenarios match what you're trying to do? I think the multiple feature/team scenario might be close: http://www.codeplex.com/BranchingGuidance/Wiki/View.aspx?title=Multiple%20Feature%2fTeam%20Scenarios&referringTitle=Home Regards, Grant Holliday From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brogan, Daniel Sent: Monday, 25 June 2007 12:51 PM To: [email protected] Subject: [OzTFS] TFS branching strategy to support releases [SEC=UNCLASSIFIED] Classification : SEC=UNCLASSIFIED Hi All, A client of mine is currently trying to find a branching structure that is supported by TFS and facilitates their release process. They have some basic requirements that their structure needs to support. The Requirements: * Fixed date, monthly releases of a single large product into an environment that they control. * If a sub project (feature/bug fix) does not make it make by the release date it is pulled rather than extending the release date. * Only one version of the software is supported at a time. That is each month, each environment is updated with the latest monthly release. * Some sub projects are completed within a development month while others are longer running (i.e. they forward integrate changes each month into their project). * They work in an agile environment and wish to avoid code freezes. They currently achieve this by branching early. The Background: Currently they have the following structure: Below PSP stands for Product Sub Project e.g. product feature or major bug Main Line --> Integration Line --> PSP 1 --> PSP 2 --> PSP 3 --> PSP 4 So as an example, in preparation for a release PSP 1 and PSP 2 are reviewed, tested and then reverse integrated (RI) (merge up) into the integration line. Integrations testing goes well, sponsors sign off and the product is moved into prod. Somewhere during this process a PSP that is releasing would usually request a new branch to start working on next months work or even two branches to support multiple months of work. Main Line --> Integration Line --> PSP 1 (last month) --> PSP 1b (current work) --> PSP 2 (last month) --> PSP 2b (current) --> PSP 2c (future work) --> PSP 3 (ongoing) --> PSP 4 (ongoing) Everyone forward integrates (merge down) from the integration line on stable labels (usually a release label). No one works on the integration line directly. The Problem: The issue they have is what to do if a project gets pulled out of the release at the last minute (after being merged and checked-in to the integration line). This is usually due to problems beyond their control (e.g. no sponsor sign off or major bug found late in testing). How do they reliably rollback multiple merges for a single PSP out of the integration line? Also bear in mind that there are usually multiple RI merges per PSP for each monthly release. Rolling back large un-sequential merge changesets seems unpredictable. Also most other branching patterns I have seen either have too many baseless merges (only a problem in TFS) or assume non fixed release dates that are further apart. So I am turning it over to you. Any ideas? Regards, Daniel ********************************************************************** WARNING This email message and any attached files may contain information that is confidential and subject of legal privilege intended only for use by the individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient be advised that you have received this message in error and that any use, copying, circulation, forwarding, printing or publication of this message or attached files is strictly forbidden, as is the disclosure of the information contained therein. If you have received this message in error, please notify the sender immediately and delete it from your InBox. AFP Web site: http://www.afp.gov.au ********************************************************************** OzTFS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. View the web archives at http://www.mail-archive.com/[email protected]/ Powered by mailenable.com - List managed by www.readify.net OzTFS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. View the web archives at http://www.mail-archive.com/[email protected]/ Powered by mailenable.com - List managed by www.readify.net OzTFS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. View the web archives at http://www.mail-archive.com/[email protected]/ Powered by mailenable.com - List managed by www.readify.net
