2

I have a very simple question regarding the Standard Branch Plan.

I understand branching, FI and RI, etc.  What I don't quite understand is how to use the Servicing branch in practice.

My understanding is when it comes time to release, I branch Main -> R1.SP1 (assuming this is my first release, for example) and then immediately branch R1.SP1 to R1.  Then set R1 to Read Only.  This I completely understand and like.

Here's what I don't understand:  How and when do R1.SP1, R1.SP2, R1.SP3 get created?

Do I RI SP1 back to main and then branch main to SP2/3/n as time goes on?

Said another way, how are these future SPs populated with changes for their own release/deployment?

For example, if a customer reports a bug in R1, where do I check code out from to make this change and where do I check in/commit the changed/fixed code back into?  Do I check in to the SP1 branch? (Because the R1 branch is read only).  Then what? 

I guess I am asking where is my sustaining development happening to create the future SPs for R1 and how do these get created and prepped for their own releases/deployment?

A very simple step by step scenario example would be most helpful/appreciated.

Please, if my question is not clear, let me know and I will do my best to revise it.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
Worlds Local Yank
  • 59
  • 1
  • 11

1 Answers1

2

Not a TFS specialist, but what I read is:

  1. Developers only need to check in once based on which release vehicle the change is for (i.e. Hotfixes go into the product HOTFIX branch).
  2. No need for baseless merges. Create a natural merge path back to MAIN by creating a hierarchal branch structure based on your release vehicles.
  3. Reduce risk of regressions. By creating a parent/child branch relationship between MAIN->SP-> and HOTFIX branches changes are naturally merged into future release (i.e. Hotfixes merge into the SP branch on their way to MAIN) reducing risk of bug regressions in future releases.

After the release branches are created changes from MAIN you should not merge (FI) into the release branches.
Changes should merge – one way – from RELEASE to MAIN.
Also, changes should always merge through intermediate branches (i.e. RELEASE -> HOTFIX -> SERVICEPACK -> MAIN) to ensure that bug fixes remain consistent in subsequent releases.

Advanced branch Plan

I think that last section explicitly mentions how the workflow of merges should go once a version has been released into production.
It should go back to main until enough has been consolidated in order to create a new set of ship vehicles (from servicing, where you choose a version to start your new SPx, to Hoyfix.spx, to release.spx)

The OP user1448758 points out in the comment the article Where do I fix a production defect? which mentions:

The Release branch is a child of the hotfix or servicing branch, rather than in a separate branching structure. This allows you to have multiple active release sets (consisting of Service Pack, Hotfix, Release branches) for each of the minor or major releases you need to support in parallel.
The hotfix would be applied to the specific release the bug is found in, and then merged (RI) to Main and possibly into vNext development branches.

Since the development branches are working on vNext work after vCurrent is released, I discourage you from fixing defects found in vCurrent (post-release) in the vNext development branch.
After you release Sprint 1, you should fix defects (post-release) in Sprint 1 on the release side, and fix bugs (pre-release) in Sprint 2 on the development side (vNext).

Release is a child of hotfix. At the time you create the release, the contents of hotfix and release are the same.
Release is made read-only and Hotfix is available for making defect fixes against what was released.

The problem with inverting the structure, is you cannot move a hotfix to Main without going through Release, and doing so means you no longer have a copy of the code as released.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thank you so much for your considered answer. So, taking your diagram above, let's say that I have only released r1. I've created the hotfix and release r1.sp0 branches and built my .exe from the release branch, and set it to read only. Now, 1 week after the r1 release a user calls with a bug. First, where should I check the code out from to start working on it? Is it from the read only r1 branch? – Worlds Local Yank Sep 16 '12 at 04:33
  • Second, once I've made the code fix, where do I check into? The r1 branch is read only so I assume I am checking it in (i.e. commit) to the hotfix branch then merging it back to into servicing and then main. Is this correct? Thanks again for your response. – Worlds Local Yank Sep 16 '12 at 04:33
  • Hi @VonC. I think I found an article that answers my question: ["Where do I fix a production defect?"](http://blogs.msdn.com/b/billheys/archive/2011/03/22/where-do-i-fix-a-production-defect.aspx). I think at this point I just need to practice this approach to get the answers to my question. Thanks again. – Worlds Local Yank Sep 16 '12 at 05:13
  • @user1448758 good link: I have included the relevant extracts in the answer for more visibility. – VonC Sep 16 '12 at 08:25