Agile version control?

Question

I'm trying to work out a good method to manage code changes on a large project with multiple teams. We use subversion at the moment, but I want more flexibility in building a new release than I seem to be able to get with subversion.

Here's roughly I want:

• for each developer to create easily identifiable patches for the project. Each patch delivers a complete user story (a releasable feature or fix). It might encompass many changes to many files.
• developers are able to easily apply and remove their own and other patches to facilitate testing
• release manager selects the patches to be used in the next release into a new branch
• branch is tested, fixes merged in, and ultimately merged into live
• teams can then pull these changes back down into their sandboxes.

I'm looking at stacked git as a way of achieving this, but what other tools or techniques can deliver this sort of workflow?

Answer 1

It sounds to me like you need a continuous integration facility like Cruise Control, Hudson, Cruise, Team City, etc.

Answer 2

If your stories are truly isolated and very additive (very little changes to existing code lines), the approach might work. However, as work becomes more and more intertwined, merges are going to become increasingly difficult.

CI environments, as suggested by duffymo will help, but those tools from my experience don't have many (or any) features to build lots of versions of the project nor be smart about mixing/merging branches.

It might be better to take more of a hierachy approach. Each group should have it's own CI and then promote to a master version system/CI system when it's appropriate (end of each group's sprint?). This would minimize the painful interactions for the group, but allow the project as a whole to continuously move forward. If you have a lot of groups, add some additional levels of integration.

Note, in this approach, unit tests can stay at the group level, but you will need to find ways to write integration and system tests that can work across the high level builds.

On the toolage side, any of the CI toolsets should work. For version control, Git and Mecurial support this type of approach (others may as well).

Not exactly what you're asking for, but I don't think there are many tools that are addressing the type of approach you want to take. Also, I think that a reasonable number of stories cause a level of refactoring of existing that is going to make mixing and matching changes, difficult.

Answer 3

This is a wishful thinking unless, as already stated, each feature does not overlap at all. That's an exception and not the rule.

A better way to go about it is to actually be involved with the team(s) and get an idea of when some features may be getting close to complete. Have these branch teams merge their branches together as they develop. Merging them into the development branch and then into master upon release will be very easy.

There are a few points to add:

Rebase when possible, especially if one feature has not been worked on for a while. Rebasing will solidify conflict resolutions in a linear history. Subsequent merges or rebases will not have to revisit these decisions - at which point recollection may not be as accurate.

Use the --no-ff (no fast-forward) option when merging one branch into another. This ensures that if the second branch has no commits to merge with, an empty commit is added that notes the two branches merging. If this is not done, you can loose a branch point. This can be important information.

HTH,

Adam

Answer 4

I'm trying to work out a good method to manage code changes on a large project with multiple teams.

I highly recommend to read Henrik Kniberg's article Version Control for Multiple Agile Teams on InfoQ.

In short:

• The trunk contains DONE DONE stories, it has a releasable policy (can be released at any time).
• Development is done in work branches (one per team), they have a softer policy (unit tested).
• when a story is DONE, it is pushed from the work branch to the trunk.
• Merge from trunk to work branches are done every day.

Here is an illustration of a whole sprint:

This is an extremely simplified version of Henrik's paper, but that's the spirit. It's totally compliant with our process (Scrum) and works very well for us.

PS: By the way, I don't really understand why developers would work during an iteration on something that the release managers wouldn't pick for the release.