Agile Version Control for Multi-Team Development
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
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.
Branching & merging
Cimple and Clear
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.
One of the best articles on the topic I have read.
Very easy for code...
Experience from implementing this model
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...
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
lao shing kit
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
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.
Any arguments for using this branching approach and not branch-for-release?
Re: Wrong diagram
If you make the bug fix on 2.4 then chances are you would branch 2.4.3 subsequently.
Excellent article - couple of clarifications
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
I tried to find a comparison outside of the vendor sites, but this seemed reasonable.
Re: Agile version control
GIT version of this model
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.
The Persian Translation is now available.
Thank you for your great article.