Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>Question: If "Release B" is created BEFORE a "Development" project is completed, then a "Hotfix" for "Release A" is required, how do I propagate that "Hotfix" from "Release A" into "Release B" without picking up any "Development" projects that get completed in the meantime?</p> </blockquote> <p><strong>Short Answer:</strong> For the specific scenario described I believe you could safely merge From Release A through Main and then back up to Release B. (Yes, this is identical to what Geoffrey McGrath stated in a comment on 8/16.) Typically you don't do any FI merges from Main to a release branch after creating the branch, but if you can confirm the only change present in Main is your hotfix then the merge should safely accomplish your goal. <strong>HOWEVER</strong> this is based on the very questionable assumption that you have a clean Main branch with nothing else has merged into Main since "Release B Servicing" was branched. Verify this assumption very carefully before proceeding!</p> <p><strong>Dirty Main workarounds - cherry picking or baseless merge:</strong> If there are other changes in Main they you can cherry-pick merge the specific hotfix from Main to "Release B Service Pack". Another option is to do a baseless merge from "Release A Servicing" directly into "Release B Servicing" which bypasses any other changes in Main. (You still need to merge this fix through main so Dev branches get the hotfix.) Note that cherry-pick merges and baseless merges have higher risk than regular merges (which can be tricky enough as-is). Still they are valid options for specific scenarios where no better solution exists.</p> <p><strong>Meta-answer#1:</strong> I find drawing a diagram helps me follow the changes from original branch to the final destination. Cherry-pick doesn't have any special notation, but baseless merge can be arrow with dotted line. If it works on paper (and you accounted for all other branch interactions with Main) then it should work.</p> <p><strong>Meta-answer#2:</strong> If above hasn't outright answered your question then I'd recommend reading the <a href="http://tfsbranchingguideiii.codeplex.com/discussions" rel="nofollow">http://tfsbranchingguideiii.codeplex.com/discussions</a> forum and cross-post this specific request. Bill Hays is typically very responsive in that forum and your question definitely points to hotfix management within TFS branching. </p> <hr> <h2>FYI:</h2> <p>My team works on a few SOA (Service Oriented Architecture) projects which encounters similar challenges to SaaS. The one month QA cycle is a tough complication.</p> <p>I like Martin's article a lot (enough to cite it again below). There are two additional articles worth reviewing (both have pretty pictures to augment nice TFS Branching Guide diagrams). However all three articles focus on dev branch management rather than hotfix release branch management (same as diagram in the earlier answer). </p> <ol> <li><a href="http://blog.hinshelwood.com/archive/2010/04/14/guidance-a-branching-strategy-for-scrum-teams.aspx" rel="nofollow">Guidance: A Branching Strategy for Scrum Teams</a> - Martin Hinshelwood 2010.04.14 - Excellent walkthrough of basic "branch by release" strategy as a Scrum team works through 2 sprints (with great diagrams).</li> <li><a href="http://blogs.msdn.com/b/billheys/archive/2011/01/18/branching-for-scrum.aspx" rel="nofollow">Branching for Scrum</a> - Bill Heyes (ALM Ranger) 2011.01.18 - Excellent scrum team diagrams and scaling branches.</li> <li><a href="http://blogs.msdn.com/b/billheys/archive/2011/01/14/parallel-feature-teams-working-on-multiple-releases-in-development-monthly-releases-to-production.aspx" rel="nofollow">Parallel Feature Teams working on multiple releases in development</a>. Monthly releases to production. - Bill Heyes 2011.01.14 - Very similar to our branching scenario (3 Web dev teams + 1 Prod env.). Guidance is Branch by Team + Branch by Release.</li> </ol> <p>Enjoy! -<em>Zephan</em></p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload