Release management with a distributed version control system

Posted by See Sharp Cheddar on Stack Overflow See other posts from Stack Overflow or by See Sharp Cheddar
Published on 2010-05-15T04:57:53Z Indexed on 2010/05/15 5:04 UTC
Read the original article Hit count: 241

Filed under:
|
|
|

We're considering a switch from SVN to a distributed VCS at my workplace.

I'm familiar with all the reasons for wanting to using a DVCS for day-to-day development: local version control, easier branching and merging, etc., but I haven't seen that much that's compelling in terms of managing software releases. Here's our release process:

  • Discover what changes are available for merging.
  • Run a query to find the defects/tickets associated with these changes.
  • Filter out changes associated with "open" tickets. In our environment, tickets must be in a closed state in order to merged with a release branch.
  • Filter out changes we don't want in the release branch. We are very conservative when it comes to merging changes. If a change isn't absolutely necessary, it doesn't get merged.
  • Merge available changes, preferably in chronological order. We group changes together if they're associated with the same ticket.
  • Block unwanted changes from the release branch (svnmerge block) so we don't have to deal with them again.

Sometimes we can be juggling 3-5 different milestones at a time. Some milestones have very different constraints, and the block list can get quite long.

I've been messing around with git, mercurial and plastic, and as far as I can tell none of them address this model very well. It seems like they would work very well when you have only one product you're releasing, but I can't imagine using them for juggling multiple, very different products from the same codebase.

For example, cherry-picking seems to be an afterthought in mercurial. (You have to use the 'transplant' command). After you cherry-pick a change into a branch it still shows up as an available integration. Cherry-picking breaks the mercurial way of working.

DVCS seems to be better suited for feature branches. There's no need for cherry-picking if you merge directly from a feature branch to trunk and the release branch. But who wants to do all that merging all the time? And how do you query for what's available to merge? And how do you make sure all the changes in a feature branch belong together? It sounds like total chaos.

I'm torn because the coder in me wants DVCS for day-to-day work. I really want it. But I fear the day when I have to put the release manager hat and sort out what needs to be merged and what doesn't. I want to write code, I don't want to be a merge monkey.

© Stack Overflow or respective owner

Related posts about dvcs

Related posts about distributed