3

My development team is migrating from SVN to Mercurial. Having researched DVCS best practices, it has been suggested that we develop against feature branches of the repo mainline, test them separately, then cherry-pick the features we want in each release, before merging those selected branches into the mainline and eventually releasing it.

Question: What I'm looking for is recommendations for some sort of software tool that will make my role of "software release manager" easier, in that it will allow me to control (cherry-pick) which branches (features, bug fixes, etc) are merged (using Git, or Mercurial) into which software releases (in each environment), and be able to produce the binary deployment artefact.

Our applications are mostly Java Web apps, with a handful of Java Applications, and the projects built using Maven (v2).

I've looked around for release management tools, but nothing really fits the bill.

NB: Not all changes are released as soon as they are completed and pass QA - some are to be released at a later date, as part of a themed release

Things dismissed so far (based on recommendations in similar questions, in other SE threads):

  1. Trac (seems to be just PM type stuff, which we already have with the Atlassian OnDemand offering)
  2. Jenkins (plus other CI tools) - am looking for something to manage my releases, rather than a CI tool (we have used Jenkins in the past).
  3. Mercurial Patch-Queues - I may well need this, but was looking at some sort of "nicer" interface to help me manage it.
  4. ERP offerings - TBH, I didnt look too much into this option, as my initial feeling was that they were too heavy-weight.
  5. BuildMaster, by Inedo - This was the closest match, by far, but was not quite suitable due to its lack of VCS branch picking/merging functionality. I would say however that this is a very nice piece of software, and would recommend it, if it fits your use-case, and is sensibly priced, even for Enterprise use.

Am currently evaluating the following tools:

  1. Bitbucket Feature Branch management (since we use Bitbucket for our projects, seems prudent to evaluate their approach)

Since DVCS is new to us, these things may have been dismissed prematurely, so feel free to re-educate me. :)

7
  • "I've looked around for release management tools, but nothing really fits the bill" - would you mind listing (some of) the tools you dismissed in the research you performed prior to asking here?
    – gnat
    Mar 14, 2013 at 7:58
  • 1
    Sure, added what I think are not suitable
    – Crollster
    Mar 14, 2013 at 8:16
  • iirc tortoiseHg has a gui for MQ
    – jk.
    Mar 14, 2013 at 15:25
  • 2
    Before going the feature branch route consider doing martinfowler.com/bliki/FeatureToggle.html instead
    – Joppe
    Mar 15, 2013 at 7:58
  • 3
    Never use FeatureToggle - it's ancient bullshit, which produced badly managed and readable code Mar 18, 2013 at 21:25

3 Answers 3

3

This may not be as automated as your want but TortoiseHG will let you select what branch you want to merge and indicate that the branch is merged. The downside is that I do not think there is a TortoiseHG mode where you can see what branches are still unmerged. You'd have to scroll throught he graph portion of the history pane to see what is what.

Edit: From the command line hg head -t will show all branch heads that do not have children and thus no merge.

I'm experimenting with the revision set filter in TortoiseHG to see if you can duplicate the result from within THG but no luck yet :-(

2
  • hg heads might fix the downside
    – jk.
    Mar 14, 2013 at 15:27
  • 1
    "The downside is that I do not think there is a TortoiseHG mode where you can see what branches are still unmerged" - there is Filter Toolbar (with correct revset it will show heads of still-not-merged branches) Mar 18, 2013 at 21:30
2

The issue I see here is more of a source management one -- what you really need to do is add a concept of a release branch which is where you can cherry pick feature branches to integrate and test. Any other tool you want to use can then be pointed at said release branch without having a whole lot off offline work.

Another variation on this concept would be to use a fork and pull requests to pull this stuff into a clean "release" repository for each release. I can't claim to have done this this way though.

1
  • Yes, that makes sense. More to think about...
    – Crollster
    Mar 23, 2013 at 11:14
0

While I can see how you build your workflow for release (is it tag in default branch or special separate branch-per-release) and topology of your repository (does later releases inherit all features from previous releases or not), I'll try only some iterations:

As already noted, I think, TortoiseHG will be good main tool

If previously-merged features inherited in later releases and naming of branches follow <some pattern> and all branches are open (differ only by the condition "already merged or not yet") and releases are tags you can use in TortoiseHG the following revsets in filter (but for producing lists CLI is better, from my POV - revset with templates will give nice output)

  • Not merged feature-branches

branch(re:some pattern) and not ancestors(tag())

(if release is not tag, but special branch - replace tag() with branch(release-branchname)

  • Branches heads (simplified version of previous revset)

head() - ancestors(tag()) or heads(all())

(may require to exclude heads of some named branches)

  • Merged into branch since last release (tag in branch)

p2(last(tag()):: & merge())

but in CLI it will be nicer with some additional templating

hg log -r "p2(last(tag()):: & merge())" --template "{branch}\n"

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.