This project has moved. For the latest updates, please go here.

Branching and Bug fixing

Apr 13, 2011 at 6:33 PM

Referring to the Branch plans (Basic, Standard, Advanced) discussed in this guidance are very useful, but this guidance is not able answer the below questions properly.


Real Life Scenario:

  1. I have an TRUNK for my base code. And Create DEV-1, DEV-2 branched from it. As per my SDLC life cycle...Once development is completed I need to move the code for System Itegration Testing (SIT), and then move to User Acceptance Test (UAT). Finally code will be moved to Production having all tests are passed.
  2. I have multiple prallel releases.
  3. Release can have bugs at any stage (SIT, UAT, PRODUCTION).

Questions:

  1. From which branch I need to move code to System Itegration Testing (SIT), and then move to User Acceptance Test (UAT)?
  2. If there are bugs in SIT, UAT where I need to fix them?
  3. Where I need to fix the production hot fixes?

Can you please clarify my questions.
- Pradeep

 

 

 

 

 

 

 

Developer
Apr 13, 2011 at 7:06 PM
Edited Apr 13, 2011 at 7:07 PM

In the branching guidance, we call TRUNK the MAIN branch. It is the parent of the development (feature) branches. I assume DEV-1 and DEV-2 are two development teams working on the same release? At some point the code from these two branches will be integrated. Our guidance recommends doing this initial integration in one of the DEV branches. For example, you could start by integrating DEV-1 with the latest changes from MAIN. Merge MAIN -> DEV-1 and test the integration in the DEV-1 branch. You could deploy the code in this branch to your SIT environment if you wish for integration testing.

Next you could integrate DEV-1 with DEV-2. We recommend doing one last merge (FI) from MAIN to DEV-1 followed by testing and then merge DEV-1 (RI) to MAIN. Next merge MAIN (F)) to DEV-2 and test the integration of DEV-1 with DEV-2 in the DEV-2 branch. You could deploy the DEV-2 branch to your SIT environment for integration testing of DEV-1 and DEV-2. If there are bugs in SIT, fix them in the DEV branch that was deployed to SIT. If there are bugs in UAT, fix them in the DEV branch that was merged to MAIN for UAT testing. In other words, defects that are found prior to release are fixed in DEV. Defects that are found after release are fixed in a Release branch.

Once the integration of DEV-1 and DEV-2 is ready for UAT, do one last merge of MAIN (FI) to DEV-2, final testing, and merge DEV-2 (RI) to MAIN. Deploy MAIN to the UAT environment for UAT testing. When UAT sign off on the build, it is ready for release. At this point you need to decide which of the branching plans you are following. Let's suggest you want to follow the advanced plan. When you are ready for release, you create the three release branches at the same point in time. First branch MAIN to ServicePack, then branch ServicePack to HotFix, and finally branch HotFix to Release. Make the Release branch read-only. If you need to support multiple releases, then add a suffix to the branch names for the release number (e.g. ServicePack 1.0, HotFix 1.0, and Release 1.0)

Make post-release (production) hot fixes in the HotFix branch for the release where the defect is found. Do not merge HotFix to Release (it is read-only). But you can merge HotFix to ServicePack and then to Main if you want the defect fix to be carried forward to vNext.

 Regards,
Bill Heys
VS ALM Ranger

 

 

Apr 14, 2011 at 4:23 AM
Edited Apr 14, 2011 at 7:00 AM

Hi Bill, Thank you for immediate response.

Question#1
In my case DEV-1, DEV-2 are two different branches for 2 separate relases. If take code from DEV branches for SIT release, then how to do integration testing?
As per your TFS 2010 Branching guidance, it seems all relases (SIT, UAT) must be through the MAIN branch. And DEV branches are only for development and developer unit testing.

I think all deployments for TEST/Production must be taken from MAIN branch, as it a stable from development point of view and contains all completed code from several DEV branches.

Correct me if I am Wrong.

Question#2
As per your reply, we need to give SIT release from DEV branches and UAT realse from MAIN branches.
This leads to increase in number of merging activities in SIT release, if you N number of DEV branches.
How about taking SIT release from MAIN branch similar to UAT realse?

Question#3
As per TFS2010 Standard Branch Plan...
1. HotFixes/ShipStop bugs will be fixed and checked-in to RELEASE branch and release goes to production from here it self.
2. Any ServicePack workitem will be fixed and checked-in to SERVICEPACK.

How to move to this Service pack to production. can we take directly from existing SERVICEPACK branch? or need to create other RELEASE branch?
Is it required to create multiple SERVICEPACK / RELEASE branches for a single major release?
i.e, if a major release contains more than one SPs, then is it required to create multiple SERVICEPACK branches with the version number?

Please clarify.

- Pradeep

Developer
Apr 15, 2011 at 3:37 PM

I am not sure I totally understand your questions.

If DEV-1 and DEV-2 are development branches for two separate releases, why not simply deploy from one of these branches for SIT testing. I have no problem deploying from ANY branch to a testing environment. When you are stabilizing code for release, it makes sense for Main to be deployed to QA for stabilization testing (or UAT).

When I deploy to test, it is a deployment activity (build and deploy) from a branch to a testing environment. It is NOT a branching or merging activity. I don't understand Question 2 in this context. You would not have N Dev branches simply because you have N testing environments.

With respect to question 3, we never check changes into the release branch. if you need to make hot fixes separate from service packs, you should consider the Advanced plan.

Read my blog http://blogs.msdn.com/b/billheys/archive/2011/03/22/where-do-i-fix-a-production-defect.aspx, it might answer some of your questions.

Regards,
Bill Heys
VS ALM Ranger

Apr 17, 2011 at 4:42 AM

Regarding your point...."When you are stabilizing code for release, it makes sense for Main to be deployed to QA for stabilization testing (or UAT)."

Consider the below case of 2 releases and their dates:

ReleaseName-----DevBranchName------SIT Release-------UAT Release-----------Prod Release
_____________________________________________________________________________________________________________
R1                       Dev-1                      Jan-1                  Jan-10                       Jan-20
R2                       Dev-2                      Jan-15                Jan-25                        Feb-05

Jan-16: By this date, R1 will be in UAT, and R2 will be in SIT.
Jan-17: Got bugs in both R1-UAT, R2-SIT, need to provide the fixes to both.
Jan-18: R1-UAT bugs are fixed in Dev-1 branch, and R2-SIT bugs are fixed in Dev-2 branch. Need to provide these fixed to R1-UAT, R2-SIT

having this scenario, I need to merge (RI) fixes to MAIN and give the patch. This leads the possibility of R1-UAT having the code related to R1. This should not happen.

My Approach to the solution:

  1. Create DEV braches from MAIN, for each main release.
  2. Deploy DEV branches code for SIT/UAT, by merge (FI) code from MAIN.
  3. Fix any bugs found in SIT/UAT in DEV branches itself.
  4. In between, if there are any updates to MAIN (RI merge from any other Stable DEV to MAIN) - do the FI merge immediately to all running DEV branches, followed by the testing.
  5. Once UAT is passed (confirmed the code is stable) do RI merge from DEV to MAIN and Create MAIN > SERVICEPACK > RELEASE branches to move code to Production.
  6. Hot fixes will be done in RELEASE branch itself.
  7. Maintenance Release work will be done in SERVicePACK branch.

Is my approch correct? Please verify and provide your valuable suggestions.
Thank you for your time spending on this thread.

- Pradeep.