3

We are going to swap to Mercurial. A piece in our plan that is missing is how to manage branching/merging of build to Test Box (and LiveBox) so isolated features can be mixed with the StableRelease and built to TestBox.

For instance, it seems the predominant usage is to have

  • DefaultStableBanch
    • TestBanch
      • FeatureABranch
      • FeatureBBranch

Development on FeatureA and FeatureB, will happen at the same time. It looks like predominant usage is to have cloned repositories with branches for the above.

Scenario 1 : If we build to test, we would merge LiveCode+FeatureA+FeatureB. If all goes well then we can merge the changesets to upstream to DefaultStable branch and build to LiveBox with FeatureA and FeatureB. job done.

Scenario 2 : If we build to test, we would merge LiveCode+FeatureA+FeatureB, and QA shows there is a problem with FeatureB. We do not want to build FeatureB anymore. We do want to progress FeatureA. We want to re-test with FeatureA on it's own and let QA pass that. Then release that to Live and hence business agility.

Questions : If FeatureB fails QA , we need to take out FeatureB changeset nodes from the Test Branch, build to TesBox again and then hopefully then merge upstream to DefaultStable branch to LiveBox.
What is the best way of removing the FeatureB changeset nodes, from the TestBranch, since 1. we need more dev on FeatureB, and the FeatureB nodeset is not finsihed. 2. We need to isolate DefaultStable+FeatureABranch and build that to test

How are other people managing this ?

user206890
  • 531
  • 6
  • 17
  • Are you foreseeing problems with B when A is present, or B by itself? or both? – Lasse V. Karlsen Mar 14 '11 at 13:06
  • I am trying to defend against a Bug in A, which the developer of A does not see. But, is fixed by some code in B. So, delivering A and B together to test will not manifest the bug. Releasing A to test on it's own will manifest the bug. Perhaps to others it seems unlikely BUT, an ORM dal is shared between A and B and ... aggregate roots are significant shared peices of code that are being worked on all the time that can cause this scenario. Also, SQL build files etc etc ... – user206890 Mar 14 '11 at 14:48

2 Answers2

2

There are a lot of great writeups up Mercurial workflows, including:

All of those use Named Branches very minimally -- definitely not one per feature, which with clones as branches sounds like the work mode you (and I) prefer.

Hitting your specific question, if the combination LiveCode+FeatureA+FeatureB is failing tests the the best way to handle it is to just keep repairing FeatureB and then merging those changes down into FeatureA + Feature B. However, before you get to that stage it's a good idea to have QA hit LiveCode+FeatureA and LiveCode+FeatureB separately too, it's slightly more work for them (more test targets) but having each feature in isolation helps find the cause of the defect more quickly.

Once LiveCode+FeatureA and LiveCode+FeatureB are passing QA, then you merge them into LiveCode+FeatureA+FeatureB and if that still passes tests merge the whole thing into DefaultStable. There should be no need to remove FeatureB from a LiveCode+FeatureA+FeatureB because you can always just create a new clone of LiveCode and merge in only FeatureA if you want it.

Here's a great writeup of a Mercurial (Kiln) based QA/release process:

http://blog.bitquabit.com/2011/03/10/when-things-go-well/

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
Ry4an Brase
  • 78,112
  • 7
  • 148
  • 169
  • I'm not suggesting named branches either, although I think that's what you're implying. If you aren't implying that, then my apologies. – Mikezx6r Mar 14 '11 at 14:24
  • Cheers, thanks for your answer, we will look at the references. In my mind I was assuming default, test branches in the Stable, Test and FeatureA, FeatureB clones. Perhaps there should be FeatireA, FeatureB named brancjes in the all the repos everwhere. That way we know which chnageset nodes were in which Feature ... – user206890 Mar 14 '11 at 14:24
  • Cheers, thanks for your answer, we will look at the references. In my mind I was assuming defaultStable, test branches in the Stable, Test, FeatureA, FeatureB clones repos. Perhaps there should be FeatureA, FeatureB named branches in the all the repos everwhere. That way, we know which changeset nodes were in which Feature when the chnagesets hit the defaultStable branch ... ? – user206890 Mar 14 '11 at 14:30
  • @mikezx6r I wasn't trying to correct your answer, I just never miss an opportunity to provide links to relevant Steve Losh write-ups because he's so bloody clear. – Ry4an Brase Mar 14 '11 at 19:31
  • OK, I read through the refs above. Probably we should follow the way Mercurial do it and maybe after a time innovate on that for something on more appropriate for our organisation. So, we can use the branch called default for new dev. A branch called stable since we are one release at a time and do not need to maintain previous versions. What about those feature branches? and the build to test ? it should mix { stable branch head + featureA branch head + featureB branch head }. ... – user206890 Mar 14 '11 at 22:42
  • ... If there is a problem with featureB then next time we build to test exclude feature b and build to test suggesting not having a permanent named test branch, but a throwaway cloned repo for this test build. Next problem, it should be the coders who merge, not the build manager since the coders have more know how about overcoming any merge problems. What will they merge with? They need to merge with the the head of the stable branch,... NO not the head of the stable branch but something the same as the head of the stable branch. ... – user206890 Mar 14 '11 at 22:51
  • It feels like everytime a coder tries to push his feature up stream for test, she needs to merge a fresh COPY of stable branch because that is what we need for test, because that is what will happen when we go to live. – user206890 Mar 14 '11 at 22:52
  • @user206890 I think you're right to understand things will change after launch. The real power of a DVCS (any of them) is that they make process and process changes easy. You're right that merging is an act of cloning. Often after QA approves a stable+feature branch you'll have code push their feature into a release candidate branch, and and when it's near release time have QA signoff on calling the candidate a release, and away you go. – Ry4an Brase Mar 15 '11 at 02:49
1

Create FeatureA and FeatureB in feature clone branches from stable. Test is merely a temporary area for QA/Test to work from, so I would treat it as 'throwaway' from day one.

When FeatureA and FeatureB are developed enough, create a clone of either one, and pull the other into QA/Test. Do the build for QA, and when they provide feedback, make appropriate changes to FeatureB.

If FeatureA is acceptable for promotion, pull it into/push it to Stable, and merge into stable.

Is that clearer than my original post?

Mikezx6r
  • 16,829
  • 7
  • 33
  • 31
  • We will work with clones. Yep, it's the obvious answer, but in my research on Mercurial usage there is no obvious explicit statement of this. It seems like people are branching FeatureA and FeatureB from Test branch and holding onto this long running Test branch. A In your way perhaps you can pull from defaultStable clone and push to Test Clone ... see http://hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html at the bottom ... [paths]default = http://www.selenic.com/repo/hg default-push = http://hg.example.com/hg – user206890 Mar 14 '11 at 13:54
  • The problem is you won't find a definite answer, as there aren't any. The beauty, and yet pain of a DVCS is it allows you to work in many ways, and leaves it to you to determine which is best for your circumstance and constraints. I'll attempt to edit my answer to be more specific, and provide a couple alternative approaches. – Mikezx6r Mar 14 '11 at 14:05
  • Yes your right, there is no right answer. Cheers, thanks for your answer, we are trying some experiments ... – user206890 Mar 14 '11 at 14:24