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: 266
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