Agile Version Control for Multi-Team Development

by Deborah Hartmann Preuss on Apr 16, 2008 |
Without the disciplined practice of version control, any team's agility is severely at risk - the ability to refactor freely, experiment safely or recover quickly from error is compromised without this safety net.Many Agile proponents see version control as a central practice - not just for Agility, but for professional software development in general. For new teams, or those without a consistent approach to version control, help is here. Henrik Kniberg's clear explanations are familiar to many from his popular InfoQ minibook, Scrum and XP from the Trenches. Now he has shared the details of the version control method used in that book, in his latest article Version Control for Multiple Agile Teams.

Henrik's method is described as a complete pattern, with all elements carefully described. An emphasis is placed on a clear understanding of what "done" means, and he proposes that this must include regression. The pattern includes
  • Branch owner & policy
  • The "done" concept
  • The Done branch
  • When do we create additional branches?
  • Work branches
  • Publishing from work to trunk
  • What if our team implements multiple stories in parallell?
  • Done includes regression testing!
  • Diverging code (merging conflicts)
  • Multiple teams - what if other teams are publishing to the trunk as well?
  • Release branches
Going further, Henrik also includes some variations to this model, a FAQ and a list of references. It's a long, thorough article, but easy to understand.
 



The preceding diagram is an excerpt from the cheatsheet that accompanies the article. Graphics play an important part in explaining Henrik's approach so, in addition to the printable InfoQ version of the article, a separate printable .pdf is provided, as well as a one-page summary .pdf (cheatsheet) for developers to print and post as reminders at their work stations.

Related Editorial

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Branching & merging by George Ludgate

The branches and merges of a lump of code has EXACTLY the same shape as that of the PERT Chart for the Project working on that code. I thought that is what the article would explain given that the figure near the title looks a little like an unfinished PERT. Even if you add in daily integrations this maxim remains true. So the PM decides the structure. It is never arbitrary or up to the Coder.

Cimple and Clear by Paulo Suzart

Great article, it covers the most commom troubles in mostly development enviroment even using other than XP methodologies.
Whatever pattern used to code versioning requires communication and team members commitment. I've been watching many teams misusing and doing a big mess on version control due to their lack of organization, comunication and stuff.

Re: Cimple and Clear by Paulo Suzart

* Simple

One of the best articles on the topic I have read. by Chip Childers

Outstanding job describing and visualizing the thought process. I'm particularly impressed with the simple explanation on how to think about your release mainline's relationship with multiple development code lines.

Very easy for code... by Phil Yardley

Branching the code in this manner makes perfect sense (something we've been looking at for many months) - If you are only making code changes - everything works... but (as in most cases) you have database changes as part of your development - how do you make/merge these? the DB changes need to follow the same branch strategy as these changes are per line of code. There doesn't appear to be an easy answer - and I for one would like to here any opinions on this..

Experience from implementing this model by Alexis Le-Quoc

Firstly I'd like to join the chorus by praising the clarity and the great visualization of the problem. In a shop of 80 developers we have been pushing to get to this model and have met resistance particularly with merges, especially daily merges. You can attribute that to a mix of inadequate tools, folklore, bad experiences with cvs merge (yes cvs is not that great but the amount of effort to migrate has not been worth yet)...

We went in underestimating the cultural aspect of changing something as central to software development as source change management and it cost us numerous discussions and a consensus that got us almost there but not quite.

I'm hoping that this type of polished presentation can help people in similar situation as ours to lower the amount of resistance to change.

Re: Very easy for code... by Henrik Kniberg

One pretty convenient way is to keep the DB changes with the code changes, treat them exactly the same way and check them in together.


So when you make code changes that require corresponding DB changes, update your DB script and create an SQL migration script as well. The migration script contains SQL for migrating schema and data from the old version to the new version. Everything is checked in along with the code, just another part of the source tree.


If DB changes are frequent then have a schema update routine execute automatically upon system startup. That routine executes any new migration scripts.


If the data is critical or the migration complex then you can implement automated tests to ensure that the migration script works correctly, by having it work on a snapshot of the production database.


I don't know about your context but this strategy has worked pretty well for me.

Experience and question by lao shing kit

I have similar working model before. But there are always problem when merging from work branch to Trunk. It depends on Team disipline. There are still problems that "It works on my branch" issue. Especially for my team with multiple region developers, it always takes time to find out who causes the problem.
So, finally, we have an additional trunk between working branch and trunk called staging for integration testing the "Release" version. And it takes too much effort to do that. Any good way to resolve it?

Revision Control methods by Daniel Sobral

First, let me recommend reading Wikipedia on this: Revision Control and Comparision of revision control software.


The basics of this article works fine for the enviroments where it could be used -- when you have distributed systems, where the developers of each might be completely different software houses using different methodologies, it can't be used as is. But YMMV according to the software you are using.


This article seems to be predicated on centralized versioning systems with strong trunk support. That doesn't mean you need that -- in fact, I believe other types of versioning would work even better.


Subversion, the king of free revision control software, would work fine with it, though you'd use branching instead of trunks for some stuff, most likely.


Distributed versioning systems would probably differ a lot in the way of working, but not the very basics. So you might not have a "trunk", and instead have your local repo, and you just send the patch to the stable repository, but the ideas still apply.


The only thing I really, really disagree with is the check out in the morning/check in at night modus operandi. One change, one check in. If you stick to this rule, then merges and bug trackings will come much more easily.


So, for instance, don't check in a half-done refactoring. Yes, the size of the merge for the others on the next day might be smaller, and they might notice earlier that what they are using is gone, but they won't have the whole picture to go by, and neither will anyone looking back to see what was being done when a bug crept into the code.


Likewise, if you refactor and create a new functionality (two tasks) in the same day, do a check in for each task, not just one with everything. First, it's easier to roll back selectively. Second, it's easier to understand what was done for what reason.

Wrong diagram by Evgeny Zislis

When you explain the Firm<->Soft concept, there is R2.4.2 above R2.4 - which is kind of wrong. Since each bug-fix in R2.4 we would also want to be propagated into R2.4.2, and change is flowing down. Thus R2.4 should be above R2.4.2.</->

Any arguments for using this branching approach and not branch-for-release? by Evgeny Zislis

This article is very nice overall, but when confronted with a person saying that they want to use branch-per-release.... Just because he used to have that with ClearCase on his previous job. There are no concrete benefits that can be pointed out. Since each of these concepts applies just as well to a model of branch-per-release. So it's quite frustrating.

Re: Wrong diagram by Robert Cowham

I don't agree. The relationship between 2.4.2 and 2.4 is like 2.4 to Main. Thus normally bug fixes go to 2.4.2 (if it is being maintained) and then flow to 2.4 (and then to Main).

If you make the bug fix on 2.4 then chances are you would branch 2.4.3 subsequently.

Excellent article - couple of clarifications by Robert Cowham

This is a very nicely done article.

I would prefer to see a reference to Laura's name in the text of the "Big Picture" section (as well as references). She deserves higher billing :)

The URL for my article you linked to is slightly wrong. It should be:

Branching and merging - an agile perspective

Agile version control by Mark Anderson

I found the article well written, but is there a balance between simplifying and over simplifying at the expense of productivity and how much can be accomplished in a given sprint? More sophisticated version control tools like Accurev seem more suited for agile development environments than what you describe here using Perforce, which seems to me like a trying to fit a round peg in a square hole. You've just given it a bigger hammer to drive it home, but it seems like a whole lot of hurt for nothing.

I tried to find a comparison outside of the vendor sites, but this seemed reasonable.

www.accurev.com/scm-comparisons/accurev-perforc...

Re: Agile version control by Mark Anderson

This looked like a good resource to explain in more detail what I mean.

www.accurev.com/agile-software-development.html

Automated Merging by Kevin Dietz

MergeMagician (www.mergemagician.com) is focused on automated merging and addresses many issues raised in this article.

Russian translation by Anton Nepomnyaschih

FYI russian translation is here: anton-nix.livejournal.com/2865.html

GIT version of this model by Alexander Schwartz

There is a great post by Vincent Driessen "A successful Git branching model" (nvie.com/git-model) which presents a GIT branching pattern which is very similar. He describes all necessary git commands in detail.

Furthermore, he developed a git extension "gitflow" (github.com/nvie/gitflow) which provides high-level repository operations for this branching model.

Hence it is very simple to start implementing this model.

Persian Translation by soheil samadzadeh

Dear Henrik Kniberg,

The Persian Translation is now available.

Thank you for your great article.

Cheers

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

19 comments

Educational Content

General Feedback
Bugs
Advertising
Editorial
 InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy