Servicing Branch in Standard Branch Plan

Question

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.

Answer 1

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.

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.