This project has moved and is read-only. For the latest updates, please go here.

New to branching, have some questions

Sep 1, 2011 at 4:46 PM
Edited Sep 1, 2011 at 4:48 PM

I'm trying to see if adopting a branching strategy would benefit us. Here is our current process. Concurrent development has only happened accidentally twice in my five years with the company. Typically, work on vNext+1 does not take place until vNext is released.

  1. Changes developed.
  2. Changes submitted to testers (black-box testing only)
  3. If testing finds bugs, bugs fixed, resubmitted to testers. Otherwise, changes are released.

We are using a product called MKS to handle source control. It supports labeling files and checkpointing a project. When the changes are developed, we label the deliverables with the file version and checkpoint the project with the application version. Checkpointing gives us a way to retrieve an exact copy of the source as it existed when it was checkpointed. The file version and app version are incremented every time it's submitted to the testers. So 1.0 is submitted, testers find bugs, devs fix and submit 1.0.1. Version 1.0.1 is released, bugs found, devs fix, submit 1.0.2 to testers. When new features are added, 1.1 or 2.0 (depending on magnitude of changes) is submitted to testers and process repeats.

What would the benefits be to adopting a branching strategy (such as the Basic or Standard strategies described here)? Aside from allowing concurrent development (which would happen rarely) and a way to imitate MKS checkpoints with read-only Release branches, I can't see any.

Maybe I'm just misunderstanding things? Here's what I got from the Basic plan.

  • Dev branch is for current dev work. Once changes are complete and judged ready for testing, they get merged with the Main branch.
  • Testing occurs on the Main branch and any bugs found during testing are fixed there.
  • When testing passes, the code is branched into the Release branch and the branch is labeled with the version. If bugs are found in production, the bug fixes and testing occurs in the Release branch. These changes are merged into the Main branch and are then merged into the Dev branch if dev work is occuring.

Did I get it right?



Sep 1, 2011 at 5:25 PM
Edited Sep 1, 2011 at 5:25 PM

I think you have a pretty clear picture. One diference with Team Foundation Server is that labels are NOT immutable. Therefore one needs to be careful when using labels to lock-down a version of code. This is a clear benefit of read-only branches.

I am not familiar with MKS and how code is *pulled* and then built and deployed to either a testing environment or production environment. A key reason for branches on the *release* side of the branching model is to isolate post-release bug fixes or service packs (which are made to vCurrent or older production code) from new developement happening on vNext. If we did not isolate these activities in TFS with branches, it would be impossible for a production fix to vCurrent be checked into TFS and at the same time check-in changes to vNext. In our model production fixes (on the basic plan) are checked into the release branch. New developement happens for vNext in the development branch. No changes are checked into the Main branch - it should be as stable as possible. Changes are merged after testing into the Main branch (either from the release branch to bring a hot fix forward into vNext development, or from the development branch when it passes quality gates and is ready for final stablization in the Main branch.

Note - in the basic branch plan you have to make a choice - if you make the release branch read-only then clearly it cannot also be used for post-release sustained engineering. This is when you go to the standard plan where you have a servicing branch AND a release (read-only) branch.

I hope this helps

Bill Heys
VS ALM Ranger and WW Lead for Microsoft Services WW ALM Community.

Sep 1, 2011 at 5:51 PM
Edited Sep 1, 2011 at 5:52 PM

Thanks for the quick reply, Bill. I forgot to mention that we're evaluating TFS 2010. MKS can be quite clunky.

To answer your questions, MKS does not have automated build support (or if it does, we aren't using it). Code is built on the developer's machine and the binaries are stored with the source. Not the best solution, but our software is all internal so it works for us. Most of our software uses a simple client-server architecture, so it's a simple switch of a setting to connect to our test database or the production database.

MKS labels are mutable, but checkpoints are not. Labels happen at a file level, while checkpoints happen at the project level. It is simple to go into the project history and choose a checkpoint to look at. If changes are needed, a branch can be created from this checkpoint, changes made, and then the changes merged back into the trunk/main.

You say no check-ins happen in the main branch. So bug fixes for bugs found in the main branch would happen in the dev branch and then it would be merged back to the Main branch for testing?

I understand the Standard plan inserts a Hotfix/SP branch to handle addressing problems in the Release branches, which would keep the Release branch read-only. This would probably better duplicate the MKS checkpoint functionality.


To make sure I'm understanding things, this is what the branches would look like if we labeled all merges and check-ins.

Dev -> checkin---checkin---1.0 sent to main---bugs fixed, checkin---1.0.1 sent to main---checkin---checkin---1.0.2 merged with 1.1 work>

Main ->1.0---tested, bugs found, sent back to dev---1.0.1---no bugs, sent to release---1.0.2---1.0.2 sent to dev--->

Release -> 1.0.1---bugs found---bugs fixed, checkin---tested, good---1.0.2 release, sent to main--->

Sep 1, 2011 at 6:08 PM

At a high level, I agree with your flow. I might word things a little differently:

Dev -> checkin---checkin---1.0 labeled and merged (RI) to main---bugs fixed, checkin---1.0.1 labeled and merged (RI) to main---checkin---checkin---1.0.2 (merged from Main (FI) and combined with 1.1 work>

Main ->1.0 (merged  (RI)from Dev )---tested, bugs found, sent back to dev (essentially the bugs are sent to the developers who fix them in the dev branch)---1.0.1 (merged (RI) from Dev)---no bugs, labeled and branched for release---1.0.2---1.0.2 (merged from Release (RI) and merged (FI) to dev--->

Release -> 1.0.1 (branched from Main)---bugs found---bugs fixed, checkin---tested, good---1.0.2 labeled and merged (RI) to main--->

The problem with your illustration is the flows are difficult to line up in a text description but the understanding seems correct.

As an aside, we generally do a daily automated build in Main and, if the build is good Merge (FI) from Main to Dev daily. We probably increment the build and label  Main,, etc. (again being simplistic)

We would only merge from Dev to Main on a milestone (1.0, 1.0.1, etc)

I hope this helps
Bill Heys

Sep 1, 2011 at 6:23 PM

Thanks Bill, I think I've got it.

So in the Standard plan, you'd have a new read-only release branch for each release, and post-release defect fixing would happen and be tested in the servicepack/hotfix branch? That seems like a cleaner approach than the Basic plan.


Now, bearing in mind that concurrent development almost never happens here, and post-release defect fixes are bundled with vNext, do you think that we would benefit much from branching?