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

Using Main, QA and Dev branch. Merging Question

Nov 18, 2011 at 8:01 PM

So we have Main branch which is where UAT is perfomed prior to release. Then a child of Main, QA ,  used by our QA team and our clients QA team. Then a child branch QA, Dev, used for developement. We started out just with Main and Dev but had QA issues with client so added QA branch. Problem now is say we have 5 changesets in Dev (1 for each requirement) and merge all 5 to QA for testing in one changeset. Then client does QA and only wants to push 2 of the 5 items to Main. How can we do this since we dont want to do any baseline merges from Dev? Only the one changeset in QA is available to merge from QA to Dev. Is there a better branching plan we should use?


Nov 25, 2011 at 5:19 PM

The simple answer is you would probably have to do a baseless merge from DEV to MAIN to pick up only those changesets approved by QA.

With respect to branching plan, I recommend branching for development but deploying to QA. Rather than creating a QA branch, which effectively doubles the merges required to move a change from DEV to MAIN, I would start with only MAIN and DEV. It is possible, therefore, to deploy code from either MAIN or DEV to QA for testing.

The approach, using baseless, cherry picking merges, begins to become quite complex when you have hundreds of check-ins for all of the requirements being developed, and then you decide later to cherry pick changesets for some requirements (that are done and pass QA) and leave behind changesets for other requiements (that are not done and do not pass QA).

Eliminating the QA branch somewhat simplifies the problem, since you will merge granular changesets from DEV to MAIN rather than *consolidated* changesets from QA to MAIN (after merging granular changesets from DEV to QA).

From my perspective, there are three options where you decide at the end of an iteration to release some features (those that are complete and pass QA) and not release others:

  • Cherry Pick the changesets for completed features from DEV in a merge from DEV to MAIN. Leave behind the changesets for features that are not ready for release. This can be very challenging to do successfully, particularly at the end of a Sprint or Release when there is pressure to ship a release. Consider the possibility that Feature One makes changes to two files, and Feature Two makes changes to three files, with one of these files being changed by both Feature One and Feature Two. All of the changesets made to this file by Feature One are comingled with changesets made to this same file by Feature Two. How do you pick just those changesets pertaining to Feature One without risking the possbility that the file broken by the merge. What if you pick too many changesets? What if you pick too few changesets? What if the changes made by Feature One conflict with the changes made by Feature Two. How do you unravel this mess?
  • Develop each feature in a separate feature branch. Mege the feature branches to Main only once the feature is ready to ship (passes QA). At the end of the iteration or Sprint, when a feature is not ready to ship, simply do not merge that feature's branch to Main. As with the preceding example, however, there may be conflicting changes made in different feature branches that need to be integrated prior to release.
  • Develop all features in a single development branch. Implement feature toggling (or feature hiding) to hide a feature until it is ready for release. With this approach, features that are not done and have not passed QA will be released, but will be hidden from the user until such time as they are done (in a future release).

There are pros and cons to each of these options.

Bill Heys
VS ALM Ranger




Nov 25, 2011 at 10:13 PM

I see a deeper issue here. You described a scenario in which your team delivered 5 stories to QA and 3 were rejected as unfinished. And you are looking for systems to support this as a "normal" situation. This is actually a bad smell for your overall process.  Why would QA review 5 items and reject 3 of them as unfit to promote to main?  Were they rejected because they lacked basic quality and reliability (they crashed)? Did they break other things (introducing regression)?  Were they rejected because they did not fit the requirements? Or did aggressive QA exploration uncover things that were not considered in the original requirements? other?   Rather than trying to automate the management of this kind of situation, I am recommending you consider it a problem, stop the line, fix it, and restart the line.  You may not have considered your situation unusual or pathological. It may seem just ordinary business to you. But as Mary and Tom Poppendeick wrote

"Minimizing waste means keeping the amount of unfinished work in the pipeline at a minimum,"
"... Learning to see waste is an ongoing process of changing the way you think about what is really necessary."

Poppendieck, Mary; Poppendieck, Tom (2003-05-08). Lean Software Development: An Agile Toolkit (Kindle Locations 701-702). Pearson Education (USA). Kindle Edition."

I am saying you should examine your processes here before you jump to a decision on your branching strategy. See this article by David J. Anderson for a good explanation of why we consider unfinished work (WIP) wasteful

Speaking of processes: what processes and practices are you following?  Based on your brief description, I will take a guess that your QA testers are somewhat seperated in time and place from your developers. Is that right? Are QA testers split up among the teams and considered equal partners in the development process? Or are they more like a separate team that reviews the work of the devs after devs are "done?" You have an internal QA team and a client QA team. Are any of the client QA sittting close enough to you that you could turn and say "Hey, what do you think of this?"

If you do not reduce your WIP, and must routinely manage lots of Work In Process, then Bill Heys has given you some good tools and good warnings. But I would first look closely at your process and team arrangements and figure out why a development team can produce 5 stories and 3 of them get rejected. If you figure out how to get feedback sooner, then you can bring all your stories to "done" before the end of the sprint.