Share →
Buffer

I hope everyone had a happy new year and a safe holiday season. Now that I’m done with beginning of the year housekeeping I’m back to blogging. This is the second in a series of posts on branching strategies. Branch by Quality is the most complex and flexible branching strategy so this strategy will span several posts.

Branch by Quality

Branch By Quality - Basic

Figure 1 – Branch by Quality, basic pattern

This pattern is the ultimate in flexibility – but can also get very complex. It allows you to handle unique situations and respond to changes very quickly. It can be used for supporting multiple versions of an application or for more flexibility can be combined with Branch By Release to provide even more options for supporting multiple versions. Additionally you don’t have to manage quite as many branches as with other branching strategies. However, it does mean that the management of each branch may get complicated. It allows for branching for isolation, hotfixes and the easy promotion of code from dev to test to production.

The basic structure as shown here involves three branches (or code at various qualities) – Dev which is code that is in constant change and is therefore referred to as “soft” code, QAwhich is code that changes very infrequently (no active development is ever done on this branch) and is considered more firm than the code on the Dev branch and finally Prod which contains code which has been released to production (development is never done on the Prod branch). The red lines represent the branch hierarchy. In this case Prod is the parent of QAwhich is the parent of Dev. In reality the branching can be done in any way which creates a relationship between Prod and QA and QA and Dev. Using TFS you can branch QA to Prod and QA to Dev or Prod to QA to Dev or Dev to QA to Prod to create this relationship. The only thing this effects is the default selection of drop down boxes in the merge wizard.

The reason why we refer to this pattern as Branch By Quality is because of the quality of each branch. Dev is potentially testable, QA is potentially releasable and Prod is released code. Each branch must maintaint this quality. Another hallmark of this pattern is a single path to production. Branch by Release has multiple paths to production – each new branch is a new path to production. With this pattern, builds for production ALWAYS come out of the QA branch (not the Prod branch as you may have assumed).

The process for releasing code is to promote it from Dev to QA, build the QA branch and test the compiled assemblies. If all tests pass, you do NOT rebuild the code – you simply deploy the already compiled assemblies. Then you promote the code from QA to Prod as a safekeeping. Note also the pairs of green lines which represent merges. As before, always Merge down, Copy Up to promote the smoothest transition possible.

Dealing with Bugs

Let’s look at a simple example where code has been promoted from Dev to QA (so the users can perform User Acceptance Tests (UAT)) and development on the next release has begun on the Dev branch. In this situation, assume a bug has been found by users during the UAT and needs to be fixed. Figure 2 shows this scenario.

Branch by Quality - Bug in Test

Figure 2 – Bug in Test

Unlike Branch by Release, you cannot just make a fix on the testing branch because code on that branch is always potentially releasable which means that making changes to that branch can potentially cause problems. To avoid this you take a branch for isolation – in this case it follows almost the same pattern as performing hotfixes (discussed next) – from the QA branch. You can’t branch from Dev because if you do there is no direct way to merge from the isolation branch to the QA branch (you can do a baseless merge but in this case it causes more problems than it solves). So, take a branch from QA (at the point you promoted the code from Dev to QA and labeled the code on the QA branch) and fix the code on this branch. Perform testing on this branch and when it is ready for UAT, promote it to the QA branch. When UAT is complete and the fix verified, merge the QA branch down to the Dev branch. This ensures that the fix makes it back into the next version of the code.

This is a fairly simple example but they will get more complicated as I add to this strategy. I will do this in a new post in the near future.

Print Friendly
  • Pingback: Team System News : VSTS Links - 01/09/2008()

  • TFSWannabe

    Hi Steve,

    Could you explain this a bit more –“The process for releasing code is to promote it from Dev to QA”.

    I want to know how do you promote this code physically?

    The place I am working currently uses a custom written program to move files that are labebled “Promote” from DEV to QA and then we perform a build. There may be files that don’t have that “Promote” label and they don’t get moved.

    I want to know how I could aceive the same in TFS or similer process to promote certain files either by their status (TFS Status such as Ready for QA) or by other available means in TFS.

    thanks in advance for your help.

  • Asher

    Yep, this sounds a bit different than the norm. Yes there should be a dev branch. Why make a production branch? Shouldn’t each production version get a branch? If my software is at v3.33 and If I want to checkout the source code for v2.34 how do I do this easily if there is only a production branch?

  • Hey, Asher. Thanks for taking time to read this blog by Jeff Levinson! As a note, this blog was written quite a long time ago, and though branching strategies may not have changed dramatically, various source control technologies and features have come and gone. In addition, development methodologies are dictating how we look at branching.

    There are certainly different opinions around branching strategies but current mindsets are that we start with a ‘main’ or ‘production’ branch and then create a child Development branch from the main branch so we isolate those changes and still be able to check them in. As you move to smaller and smaller changes or a CI/CD envrionment, the need for many branches begins to reduce. The one main argument for multiple child development branches off of main is when you are either developing multiple features in tandem and aren’t sure which one will be released this iteration. Multiple branches are expensive as they require resources when merging. The simpler the merge the less expensive it will be. So limit your dev branches. In summary – have a production branch and then create a dev branch to isolate changes.

    Once your dev branch code has been tested both on your client and then in a dev environment, you would merge that branch into Main, build that potentially releasable code, deploy it to the Dev Environment, then promote to your QA/UAT and Prod environments. Once the code has been promoted to Prod, you can then archive the code into an archive branch. It’s note necessary to archive the code to an archive branch, because you can do Get by Tag or Get by Date.

    Regarding how to do this…

    With Team Foundation Server, builds are automatically tagged with the version number, so you could easily do a “Get by Tag” to obtain the correct version of code. You could also get by date, if you knew the date. You can also get by date.

    I mentioned creating an archive branch off the production (main) branch. In some circumstances this may be a viable solution. It isn’t an expensive solution… in TFS it is just a pointer, a few bits of code, and doesn’t replicate the code in the datastore. When building applications it could make sense to have archives of specific releases (for example, Windows 95, 98, 2000, etc would each get their own branch). Also, if you are going to do this, I recommend organizing your release/archive branches using a folder.

    Personally, I would not create branches for every release, but rather create branches for major releases. As I mentioned, your builds will be tagged anyway, so you could do a ‘get by tag’ as you needed for the minor releases.

    And, just so you know, many companies are moving towards a single branch model. Iterative development and CI/CD development demands a simpler branching model in order to avoid the expense of merging and to enable short, quick little releases. In CI/CD we prefer smaller releases in order to ensure we get fast feedback. Plus, if something goes wrong it’s easier to do a roll-back, or a roll-forward to address the issue.

    Hope that helps!

  • Thanks for taking time to read this blog by Jeff Levinson! As a note, this blog was written quite a long time ago, and though branching strategies may not have changed dramatically, various source control technologies and features have come and gone. In addition, development methodologies are dictating how we look at branching.

    There are certainly different opinions around branching strategies but current mindsets are that we start with a ‘main’ or ‘production’ branch and then create a child Development branch from the main branch so we isolate those changes and still be able to check them in. As you move to smaller and smaller changes or a CI/CD envrionment, the need for many branches begins to reduce. The one main argument for multiple child development branches off of main is when you are either developing multiple features in tandem and aren’t sure which one will be released this iteration. Multiple branches are expensive as they require resources when merging. The simpler the merge the less expensive it will be. So limit your dev branches. In summary – have a production branch and then create a dev branch to isolate changes.

    Once your dev branch code has been tested both on your client and then in a dev environment, you would merge that branch into Main, build that potentially releasable code, deploy it to the Dev Environment, then promote to your QA/UAT and Prod environments. Once the code has been promoted to Prod, you can then archive the code into an archive branch. It’s note necessary to archive the code to an archive branch, because you can do Get by Tag or Get by Date.

    Regarding how to do this…

    With Team Foundation Server, builds are automatically tagged with the version number, so you could easily do a “Get by Tag” to obtain the correct version of code. You could also get by date, if you knew the date. You can also get by date.

    I mentioned creating an archive branch off the production (main) branch. In some circumstances this may be a viable solution. It isn’t an expensive solution… in TFS it is just a pointer, a few bits of code, and doesn’t replicate the code in the datastore. When building applications it could make sense to have archives of specific releases (for example, Windows 95, 98, 2000, etc would each get their own branch). Also, if you are going to do this, I recommend organizing your release/archive branches using a folder.

    Personally, I would not create branches for every release, but rather create branches for major releases. As I mentioned, your builds will be tagged anyway, so you could do a ‘get by tag’ as you needed for the minor releases.

    And, just so you know, many companies are moving towards a single branch model. Iterative development and CI/CD development demands a simpler branching model in order to avoid the expense of merging and to enable short, quick little releases. In CI/CD we prefer smaller releases in order to ensure we get fast feedback. Plus, if something goes wrong it’s easier to do a roll-back, or a roll-forward to address the issue.

    Hope that helps!

  • Asher

    Thanks for this. it is a good descriptive note