TFS Branching

What happens if:

• you and your team are working on a new set of features and the customer wants a change to his current version?
• you are working on two features and the customer decides to abandon one of them?
• you have two teams working on different feature sets and their changes start interfering with each other?
• I just use labels instead of branches?

That’s a lot of “what if’s”, but there is a simple way of preventing this. Branching…

1. A key benefit of branching for development is to isolate changes from the stable Main branch. Branching adds sanity more than it adds complexity. The primary cost is the effort to do merges and resolve conflicts. A key benefit is that you have a stable code base in Main and accept changes into Main only after they pass quality gates, etc.
2. Branch the WHOLE “Main” line. Branch parts of your code can make integration a nightmare.
   Some even go as far as to add the environments used, I prefer to think of deploying to environments (such as from Main to QA) rather than branching for QA.
3. Always do a Forward Integration from Main into Dev branch before you do a Reverse Integration from Dev Branch back into Main.
4. After branching Main to Release, we generally recommend not doing any subsequent merging (FI) from Main into the release branch.
5. In TFS, labels are not immutable. This does not mean they are not useful. But labels do not provide a very good development isolation mechanism. Branching allows separate code sets to evolve separately (e.g. Current with hotfixes, and vNext with new development). I don’t see how labels work here. Labels are not Auditable and if a dispute was raised by the customer you can produce a verifiable version of the source code for an independent party to check.
6. Branching is a tool; it is not a silver bullet. Don’t over use it, and avoid “Anti-Patterns” where possible. There is a happy between no-branching and too-much-branching.

Tools:
Team Foundation Server Power Tools v1.2 Attrice Team Foundation SideKicks

Reference:
Visual Studio TFS Branching Guide 2010
 Guidance: A Branching strategy for Scrum Teams
SSW Rules to Better Source Control with TFS
When should I use Areas in TFS instead of Team Projects

The process of completing your sprint Branch development:

1. The Team completes their work according to their definition of done.
2. Merge from “Main” into “Sprint1” (Forward Integration)
3. Stabilize your code with any changes coming from other Scrum Teams working on the same product. If you have one Scrum Team this should be quick, but there may have been bug fixes in the Release branches. (we will talk about release branches later)
4. Merge from “Sprint1” into “Main” to commit your changes. (Reverse Integration)
5. Check-in
6. Delete the Sprint1 branch
   Note: The Sprint 1 branch is no longer required as its useful life has been concluded.
   Note: In TFS deleting the Sprint 1 branch does not remove access to the to the history it just removes a future for that branch.
   Note: If you do not like this option you can lock the files on the branch or change it to read only.
7. Check-in
8. Done

Both branches and workspaces (i.e. single branch) allow you to ‘isolate’ code – a branch isolates code on the ‘server side’, a workspace isolates code on the ‘client side’.  Yes it’s true code is isolated only as long s it lives in your workspace, so you might break the build once the code is checked in.  But the same is true for branches.  A branch is not used by individuals but typically by entire teams so the likelihood of conflicts exists just the same, but now you also have the potential of merge conflicts.

You know you are on the wrong track if you experience one or more of the following symptoms in your development environment:

• Merge Paranoia—avoiding merging at all cost, usually because of a fear of the consequences.
• Merge Mania—spending too much time merging software assets instead of developing them.
• Big Bang Merge—deferring branch merging to the end of the development effort and attempting to merge all branches simultaneously.
• Never-Ending Merge—continuous merging activity because there is always more to merge.
• Wrong-Way Merge—merging a software asset version with an earlier version.
• Branch Mania—creating many branches for no apparent reason.
• Cascading Branches—branching but never merging back to the main line.
• Mysterious Branches—branching for no apparent reason.
• Temporary Branches—branching for changing reasons, so the branch becomes a permanent temporary workspace.
• Volatile Branches—branching with unstable software assets shared by other branches or merged into another branch.
  Note   Branches are volatile most of the time while they exist as independent branches. That is the point of having them. The difference is that you should not share or merge branches while they are in an unstable state.
• Development Freeze—stopping all development activities while branching, merging, and building new base lines.
• Berlin Wall—using branches to divide the development team members, instead of dividing the work they are performing.

TFS Migration Project

What happens if:

1.     You and your team are working on a new set of features and the customer wants a change to his current version?

2.     You are working on two features and the customer decides to abandon one of them?

3.     You have two teams working on different feature sets and their changes start interfering with each other?

Currently we create new release branch from previous release branch. In this scenario, if a change is not prompted in recent release, the change has to be merged through all release branches until the end. Extra test is needed to make sure this change did not break anything since the change is not based on latest release code. We also had the situation of multiple change request concurrent and feature abandoned after testing

A key benefit of branching for development is to isolate changes from the stable Main branch. Branching adds sanity more than it adds complexity. The primary cost is the effort to do merges and resolve conflicts. A key benefit is that you have a stable code base in Main and accept changes into Main only after they pass quality gates. Your goal is to merge all your change to MAIN branch as soon as possible.

Our Solution: 2 baseline branches - DEV and MAIN

1.     DEV branch contains all development done changes, corresponding to our DEV/SIT/UAT environment. Main branch contains current code on PAT/Prod.

2.     When we start release process, we'll label Main branch with previous release version, and merge changes from DEV to Main by work items selected for new release

3.     All developers will work on DEV base branch. Sub branch can be created if it's required. For example change is for experimental and could be rejected. Developer should responsible for synchronizing the sub branch and DEV base branch

4.     For Production fix we work on Main branch. Please make sure label it before check in the changes. We need to merge the change back to DEV branch after fix is done.

5.     We use work items to manage the changes in DEV branch, we use labels in MAIN branch to keep history of release version.

6.     Each check in will associated with work item. Work items will be grouped by Area and Iteration. Area will category for different project, iteration will contain all release versions.

7.     All Projects will be organized in folders

8.     We'll use database project to manage the database scripts but still use existing procedure to deploy the database change.

TFS Migration Project divided by Tasks

1.     Migrate current production code to DEV branch and MAIN branch

2.     Create work item and check in corresponding code change to DEV branch

3.     Create database project to manage all SQL database objects

4.     Migrate project DBDeploymentPackageBuilder from 2008 to 2010, update to work with new structure

                                                                                                          

Some Suggestions:

1.     Use Main branch to keep all history.

2.     Create branch only if necessary, Remove the branch not used.

3.     Branch at a high-level and include configuration and source files. Do not branch too deeply.

4.     Shelve your code daily

Future improvement

1.     Work item customization according to agile process

2.     Unit test and automation

3.     Build automation

4.     Continuous delivery: relies on automation of build, testing and deployment.

Questions

1.      If changes in 2 different DEV Branch corresponding to different Main branch, how can we Handle it?

Answer: Work items can manage change set in different branch. We can use work item time line track to merge all change sets. After merge, you probably need to build 2 package for deployment