3

We are using TFS 2010 with the Basic Branch Plan outlined in the Branching Guide on codeplex for an internal web application. We have just the 3 basic branches = Dev, Main (QA/Testing), and Release (Production).

Because the app is an internal web application, we only support the single production release.

We basically develop locally and once we complete a task (a bug fix or enhancement), we commit it to Dev. We also generally do a Get Latest from Dev every day when we start work to pull down anything checked in by the other developers. After some period of time (usually a week or two), we'll decide we have enough changes to justify updating the QA site and do a Merge All from Dev to Main and then deploy the merged Main branch to a QA server for testing.

QA will then start testing the site, and after they're satisfied, we'll do a Merge All from Main to Release and deploy the merged Release branch to our production server. Sometimes we even wind up doing multiple Dev-to-Main merges before actually merging everything on up to Release.

Anyway, we've been using this strategy for a couple of months now and until recently everything was looking great. We were able to hotfix Release if we ran into some critical problem in production and then just merge it backwards. All was looking good.

Then we ran into something we didn't know how to deal with. We were given the directive of merging ONLY a single code fix on up from Main to Release (without merging everything else in Main). Now since we didn't know this was coming, when the original changeset was merged from Dev to Main, it was merged along with several other changesets. So when I went to merge from Main to Release, the only option I had was for the entire merged changset. I couldn't "drill-down" into the merged changeset and pick just the one original changeset from Dev that I really wanted.

I wound up manually applying the change like a hotfix in Release just to get it out there. But now I'm trying to understand how you prevent a situation like this.

I've read several articles on merging strategy and everything seems to recommend NOT cherry-picking changesets when you go to merge - to simple merge everything available... which makes sense.. but if you always merge multiple changesets (and they become one changeset in the destination branch), then how do you potentially merge only one of the original changesets on up to production if the need arises?

For example, if merging Dev (C1, C2, C3) to Main (becomes C4) - then how to merge only C1 from 'within' C4 on up to Release?

It makes me think we'd be better off merging every single changeset individually from Dev to Main instead of doing several at once. At least then we could easily just take one on up from Main to Release if the need arises.

Any recommendations/life lessons/etc. on handling branching/merging for this specific scenario would be greatly appreciated.

Alexander Tobias Bockstaller
  • 4,657
  • 4
  • 36
  • 58
kman
  • 2,184
  • 3
  • 23
  • 42

2 Answers2

1

In your scenario you could have done the following:

  • Rollback C4 in Main (becomes C5, because rollbacks are changesets themselves, which apply inverse changes)
  • Merge from Dev to Main again, but this time select only C1 (becomes C6 in Main).
  • Now rollback changesets C5 and C6 again, so you have all changes in Main like before. (becomes C7 in Main).

After this you have the same code base in Main as before and you can now merge C6 (which has only the changes from C1) from Main to Release.

However, to prevent such trouble in future you should really consider merging every single changeset from dev to main separately.

Community
  • 1
  • 1
Alexander Tobias Bockstaller
  • 4,657
  • 4
  • 36
  • 58
  • i was afraid you'd say that. :) merging every changeset separately may really be our best bet. i guess that just seemed like an uncommon way to merge based on my reading - but then again it's hard to find information specifically about this particular scenario. thanks for the response. – kman Sep 27 '12 at 03:41
  • It's also a common practice to have not just one Dev branch, but one for each feature. You can also have separate branches for bugfixing, but I have more often seen fixes being applied to the Main branch directly. Having one branch per feature helps you in that you can have many changesets per feature, but when integrating the feature you can merge all changesets into one on the target branch. That way you still have the possibility to cherry pick, but you don't need to merge every single changeset separately. – Alexander Tobias Bockstaller Sep 27 '12 at 07:10
  • Having one branch per feature hides a planning dysfunction within your organisation. It is only common practice because of that lack of planning and the ideal branch structure is a single line even with multiple large teams. – MrHinsh - Martin Hinshelwood Sep 27 '12 at 16:14
1

I would not recommend merging every single change-set from dev to main; That would be a bad idea with much additional risk!

but if you always merge multiple changesets (and they become one changeset in the destination branch), then how do you potentially merge only one of the original changesets on up to production if the need arises?

You don't and should not let the need arise.

This is probably not the easy answer that you are looking for, but there really is no easy answer. Merging every single change-set is creating a massive amount of effort to prepare for something that should not be happening anyway. Indeed the process of merging individual change-sets introduces yet more complexity that will, in the end, bit you in the ass when you can't figure out why your software is not working... "dam, I missed change-set 43 out of 50"...

If the result of a bug:

In your scenario it may have been better if you manually re-applied the "fix" to either a "hotfix" branch off of Release or directly to the Release line.

That is just the cost of having bugs slip through to production and I would spend a little time figuring out why this problem got passed QA and how to prevent it in the future.

If the result of an enhancement:

Did your financial (CFO) guys authorise the reduction in quality in production that is a direct result of shipping untested code? I hope that they did as they effectively own the balance statements upon which that software is listed as an organisational asset!

It is not viable to ship only one feature, built and tested with other features, to production without completing your entire regression cycle again.

Conclusion

I would not recommend merging every single change-set or feature from dev to main; That would be a bad idea with much additional risk that should be hi-lighted to the appropriate people!

MrHinsh - Martin Hinshelwood
  • 23,409
  • 5
  • 46
  • 69
  • The bug didn't actually slip through QA and get into production (sorry I may not have been clear about that). It was actually a small feature request that management decided they "had" to have in production earlier than expected. It was being tested in Main just fine (along with a few dozen other changesets). It was just that management wanted *only* that one small feature request to go on to production - and nothing else - that we ran into problems because when it was merged from Dev to Main it was merged along with several other changesets (that they didn't want promoted at that time). – kman Sep 27 '12 at 21:14
  • Man that's harsh... did your financial (CFO) guys authorise the reduction in quality in production that is a direct result of shipping untested code? I hope that they did as they effectively own the balance statements upon which that software is listed as an organisational asset! It is not viable to ship only one feature, built and tested with other features, to production without completing your entire regression cycle again. – MrHinsh - Martin Hinshelwood Sep 28 '12 at 20:12