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
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.
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.