HOL_Quick_Start_Basic_Branch_Plan_2010_v1.pdf prerequisites

Feb 20, 2010 at 7:48 AM

Hi,

First of all congratulations on an excellent product!!!

Regarding the Prerequisites section of the HOL_Quick_Start_Basic_Branch_Plan_2010_v1.pdf file, can you please provide links for the following two:

-'The Quick Start assumes you are using the Microsoft-provided Virtual PC image that has been pre-configured to support this walkthrough. If not, you will need to perform the tasks described in the Team Development Setup.doc file.'

About me. I am currently trying out the beta 2 releases on a trial win server 2008 r2 enterprise. I would really like to have access to the project collection as generated for this document. I have some questions regaring the setup of releases, including the mature branch, which I hope could be seen more clearly from this. If not I may have some more questions for you:)

Rgds,

OJ

Developer
Feb 20, 2010 at 4:04 PM

Thanks for your positive feedback. It is appreciated by the entire team.

As to your questions:

  • Assuming you have a working environment running VS 2010 and TFS 2010, you should be able to complete the lab without much additional setup. You can either define a new user with the name from the lab manual (Michaf/Michael Affronti (PM) and P@ssw0rd), or you can use any user you may already have defined with the appropriate local and TFS permissions. In our case, Michael Afffronti is given a Project Administrat role within TFS. The Team Project used in the lab is created as part of the Lab.
  • I don't think I can easily give you access to the Project Collection for the Mature Branch plan, but I would be more than happy to answer any questions you may have regarding setting up release branches. The Mature Branch plan is really just an extension of the Advanced Branch plan in the Guidance, and was intended to illustrate how the branch tree might appear after two or more releases.

Regards,
Bill Heys
VS ALM Ranger

Feb 20, 2010 at 11:30 PM

Thanks for your quick reply!

I was wondering if the refferred to Microsoft-provided Virtual PC image was basen on the rc or on the beta 2 version, and if perhaps the project collection as shown in the figures was installed with this special virtual image. I am not able to google up any such virtual pc image, except the by now old beta 2...

As to my follow up question, please refer to the TFS_Branching_Guide_Main_2010_v1.pdf dokument, Figure 19. Mature Branch Plan - Folder and Branch Structure, Servicing folder. And the TFS_Branching_Guide_Scenarios_2010_v1.pdf, Figure 9. Scenario Source Structure, Production folder. Sorry I am not able to paste them in here..

Can you please detail how this structures should look like given a scenario where there are multiple releases, hotfixes and servicepacks created and concurrent development on releases, servicepacks and hotfixes should be allowed. Regarding fig 19, why is there no V1.0?

Also, is it not 'allowed' to pass on parts of a servicepack or hotfix between say version V1 and V2? I hope to avoid concurrent dev on multiple releases, but it would be interesting to know. 

Regards,

OJ

 

 

Developer
Feb 21, 2010 at 1:25 AM

OJ,

The Rangers Branching Quick Start lab was orignally written for the Ranger Branching Guidance II, and was used with a VPC for VS 2008 and TFS 2008. With the pending release of VS 2010, and TFS 2010, I attempted to update this lab for TFS 2010. There were a number of pre-defined Team Projects defined in the VS 2008 VPC image we used with this lab, as well as several predefined users assigned to certain roles in TFS.

There are server TFS VPC images available to download from www.microsoft.com/downloads. When I have a chance, I will take a look at these images to see if any of the VS 2010 images contain the same (or similar) Team Projects that were in the TFS 2008 image. In any event, it is easy, to get a vanilla environment up and running given a few simple steps listed in my earler response,above.

With respect to the branching plans in the Rangers Branching guidance 2010, I created separate Team Projects for each type of Branching Plan, basic, standard, advanced, and mature. As such they will not exist in any of the VPC images that can be downloaded from microsoft.com. Nevertheless, they are fairly easy to create.

We also wrote an extensive Hands-on-lab (HOL) to accompany the branching guidance. We use this lab internally at one of our conferences, and have devleoped a VPC specifically for the Rangers HOL labs developed for this conference. I don't think the VPC will be available externally, but the HOL lab manuals will contain setup instructions to show people how to recreate the Team Projects, Users, etc. required for a particular HOL.

I will be uploading the Branching Lab for 2010 to this codeplex site shortly, once it passes internal review.  It is much more comprehensive than the Quick Start lab, and guides people through the process of creating Dev and Release branch plans, along with showing where and how dev features, hotfixes, and service packs are implemented.

I will respond to the second part of you question shortly.

Regards,
Bill Heys
VS ALM Ranger

 

Feb 23, 2010 at 1:32 PM

Bill,

Thank you for your answer. Looking forward to the extensive HOL and your ans to my second question.

Rgds,

OJ

Developer
Feb 23, 2010 at 6:28 PM
OJ, I just uploaded the DEVHOL204 Hands On Lab that accompanies the Branching Guidance 2010 Regards, Bill Heys VS ALM Ranger
Developer
Feb 23, 2010 at 6:58 PM

>>In answer to your question regarding fig 19, why is there no V1.0?

The diagrams depict a V1 Release - this could also have been named V1.0. They are one and the same.

>>Also, is it not 'allowed' to pass on parts of a servicepack or hotfix between say version V1 and V2? I hope to avoid concurrent dev on multiple releases, but it would be interesting to know. 

There are times when you want to make a hotfix in V1 and have it merged into V2. There are various ways to do this. One way would be to merge the hotfix (RI) back to Main, and have it be part of *future* release branches. I note *future* release branches, because once you branch for release, and open MAIN and DEV branches for vNext development, you would not want to merge (FI) from Main down to an existing release branch.

If you wanted to simply bring a single hotfix forward from V1 to V2 (where both release branches already exists, you might consider doing a baseless merge from V1 to V2. Depending on what your are bringing forward, the baseless merge might bring over latest version or might cherry pick a specific changeset(s).

Same answer with regard to Service Pack changes.

I am not sure of your remaining question: "Can you please detail how this structures should look like given a scenario where there are multiple releases, hotfixes and servicepacks created and concurrent development on releases, servicepacks and hotfixes should be allowed."

The mature branch plan is designed to show multiple releases (perhaps not with concurrent development). If you need more in this area, I will try to create a branch plan for you and post it on my blog.

Regards,
Bill Heys
VS ALM Ranger

Feb 24, 2010 at 9:38 AM

Bill,

Thanks again for your quick reply.

>>The mature branch plan is designed to show multiple releases (perhaps not with concurrent development). If you need more in this area, I will try to create a branch plan for you and post it on my blog.

This is what I am searching for and it will be great if you can do this.

First as I feel the same stuff is missing from the DEVHOL204 and advanced branching document (ref fig 43): There you have three branches V1 Hotfix, V1 ServicePack and V1 Release. How do you remember each release from this, by labelling? I was expecting to see read only branches created from each shipped version, named perhaps Release - V1.0.0, V1.0.1, V1.1.0, V1.1.1, V1.1.2, etc.

Mature branching: I am expecting to see the same read only branches. But also (with ref to fix 19 in the TFS_Branching_Guide_Main_2010_v1.pdf), where are the read only shipped releases and where are the work made? I think it would be 'cleaner' to move (or perhaps copy if the V1 branches is ment to be the overall latest version?) the two branches V1 Hotfix, V1 Release into a subfolder V1.0 and leave the V1 ServicePack where it is. Also, and I am sure the answer to this will differ depending on the goal here, which code paths between branches are the recommended ones.

Rgds,

OJ

Developer
Feb 24, 2010 at 10:05 AM

OJ,

When you branch a new version for release, in the advanced (and mature) plan, you will create three new branches for the release at the same time. These are MAIN -> SP, SP -> Hotfix, and Hotfix -> Release. So when you ship V1.0, you would make the V1.0 Release branch read only. 

We don't necessarily treat *each* hot fix or service pack this way, although you certainly could. In theory, after shipping V1.0 Release, you could be shipping hotfixes (one or more) to fix specific customer issues. Often we would reuse the same hotfix branch for multiple hotfixes, shipping each hotfix as a patch rather than full release.

You might roll-up these hotfixes to be part of a more fully-test service pack (e.g. V1.1) (doing a merge RI) from hotfix to sp. After fully testing the Service pack, you would release it to your customers (again as a patch). At this point, you could create a new Service Pack branch (e.g. v1.2) and hotfix branch (v1.2). In doing this, the previous SP branch (V1.1) would remain in the state when it was released.

You would not necessarily create a new release branch for these minor hotfixes or service packs, although there is no reason why you can't if you so desire.

As for *moving* branches into different folders after they are created.. this is likely to cause more problems than it solves. I would recommend planning your branch hiearchy and folder structure at the outset, and put the branches into their desired folders as they are created.

Regards,
Bill Heys
VS ALM Ranger

Developer
Feb 24, 2010 at 10:13 AM

OJ,

Another possibility.. when you ship a service pack (e.g. V1.1), you might create a release branch (SP v1.1 -> Hotfix v1.1 -> Release v.1.). This could open up the SP v1.1 branch for SP v1.2 work. This might be a better alternative to creating an entirely new branch for SP v1.2, since in doing so, you might be bringing vNext changes down from Main.

Regards,
Bill Heys
VS ALM Ranger

Feb 26, 2010 at 2:45 PM

Hi again,

Sorry for beeing such a nag:)

Given that the following branch relationship allows for RI only:

MAIN -> SP, SP -> Hotfix, and Hotfix -> Release

Where or how (in what branch) to ensure a stable RI merge (of hotfox or whatever) downto Main?

The moment a release is locked down the Dev and hence Main work continues and should not be merged with these releases, and hence there is no good way to merge changes. Given the additional existence of multiple maintenance branches and the need to merge between these complicates things further, but the essence is the same. Main or some other common ancestor cannot be FI merged and tested and ensured stable prior to beeing RI'ed back. To me there seems to be a need for an additional intermediate branch (child of Main that allows for RI and FI with Main) that is common to all releases and/or possibly separate for each release branch. This will enable a stable merge downto Main, and possibly assist with good merge paths between Release 1, 2 branches etc. ???

MAIN ->main, main-> SP, SP -> Hotfix, and Hotfix -> Release1

MAIN ->main, main-> SP, SP -> Hotfix, and Hotfix -> Release2

or

MAIN ->main1, main1-> SP, SP -> Hotfix, and Hotfix -> Release1

MAIN ->main2, main2-> SP, SP -> Hotfix, and Hotfix -> Release2

or a combination of both (?usefull?)

MAIN ->main, main ->main1, main1-> SP, SP -> Hotfix, and Hotfix -> Release1

MAIN ->main, main ->main2, main2-> SP, SP -> Hotfix, and Hotfix -> Release2

Rgds,

OJ

Developer
Feb 26, 2010 at 3:13 PM

I am not sure I understand all of your question.

>>Where or how (in what branch) to ensure a stable RI merge (of hotfox or whatever) downto Main?

When you branch MAIN for release (e.g. V1.0 Release which is now vCurrent), you branch MAIN to V1.0 SP, branch V1.0 SP to V1.0 Hotfix, and branch V1.0 Hotfix to V1.0 Release (which can be made read-only after shipping)

After release, if you need to fix a bug or issue in V1.0 Release, you would do this in V1.0 Hotfix, and issue a patch the customer(s) who are affected (think if KB patches for Windows)

If you want this hotfix to be part of the next V1.0 Service Pack (V1.1), you would merge it up (RI) to V1.0 SP ... later after you accumulate a certain number of hot fixes and thoroughly test them.. you could release V1.0 SP 1. You could merge these up to MAIN (RI).

You would not bring MAIN (vNext or V2.0) down into to Release until you are ready to release vNEXT (e.g. V2.0 Release).

You stabilize vNext in MAIN prior to release and fix bugs in vNext in either the Dev branches or Main.

MAIN, therefore is the stable branch. Changes can come into MAIN from two directions (RI from DEV only after DEV reaches a milestone and passes quality gates, and RI from a SP branch only when the SP branch is ready to ship and passes quality gates.

Having said all this, I don't understand your digrams above:

 >>MAIN ->main, main-> SP, SP -> Hotfix, and Hotfix -> Release1 (what is the difference between MAIN and main, and what is the -> relationship trying to show?)

I would not advocate a MAIN, main, main1, main2 branch structure.

In the Advanced plan:

when you release V1: MAIN -> SP V1.0 -> HF V1.0 -> RELEASE V1.0 (this is now vCurrent, and V2.0 is vNEXT). Main and Dev are now opened up for vNext

later when you release V2: MAIN -> SP V2.0 -> HF V2.0 -> RELEASE V2.0 (this is now vCurrent, and V3.0 is vNEXT). Main and Dev are now opened up for vNext

I don't understand this statement:

>>To me there seems to be a need for an additional intermediate branch (child of Main that allows for RI and FI with Main) that is common to all releases and/or possibly separate for each release branch. This will enable a stable merge downto Main, and possibly assist with good merge paths between Release 1, 2 branches etc. ???

The challenge with adding an entirely new level in the branch plan is that you may negatively impact code velocity by introducing an order of magnitude of merge and merge confilct resolution. It would be helpful when you talk about merging ("merge down to Main"), if you would talk about RI vs FI rather than up or down, and describe both the source and target of the merge (eg. merge (RI) V1.0 SP to Main). It becomes to confusing to follow when the details are omitted.

Regards,
Bill Heys
VS ALM Ranger

 

 

 

Feb 26, 2010 at 5:24 PM

My concern was that a (RI) merge from a stable (V1.0) SP to a stable Main could still make the resulting merged Main unstable, something that should be avoided. I take it I was wrong, and thats fine.

I am unsure of the meaning of vNext, vNEXT and vCurrent, are they names of branches or what are they?

Thanks for your time and goodbye for now.

OJ

Developer
Feb 26, 2010 at 5:45 PM

vNext and VNEXT are one and the same. vNext is the next version under development

vCurrent is the latest released version (e.g. 1.0). When you release a new version (e.g. 2.0), vNext is the next version (e.g. 3.0) and vCurrent is now 2.0.

While you develop v1.0, it is vNext, and there is no vCurrent

When you release v1.0, vCurrent is v1.0 and you begin development of vNext (eg.v2.0)

When you release v2.0, vCurrent is V2.0 and you begin development of vNext (eg.v3.0)

I don't mean to imply that merging a SP (RI) back to Main would NOT cause some instability. But it should be fairly controlled, since the code in Main should be stable and the code in SP should be stable, and you are simply stabilizing the integration of the two.

The alternatives to merging (RI) an SP branch back to Main, in my opinion are not pretty.

Regards,
Bill Heys
VS ALM Ranger