Tracking change and innovation in the enterprise software development community
Create REST
-enabled Web Apps
with Project Zero
from IBM.
Terracotta:
Scale your
Apps w/ease
Offload the DB:
Learn More!
IBM WebSphere
Virtualize apps
to lower costs,
Increase agility
Learn more!
QCon San Francisco
Nov 19-21:
+ 80 sessions & tracks
Register now
and Save $400!
Posted by Deborah Hartmann on Apr 16, 2008 10:20 AM
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.
IBM Agile Development eKit: Free Articles, Expert Q&A, Educational Resources
Software Quality Survival Guide
The Agile Business Analyst: Skills and Techniques needed for Agile
Scaling Agile on large teams & Being Agile every day Tracks @ QCon SF Nov 19-21
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.
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.
* Simple
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.
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..
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.
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.
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?
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.
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.
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.
Thin client paradigm characterized by web applications is a kludge that needs to be repudiated. Old compromises are no longer needed and it's time to move the presentation tier to where it belongs.
In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.
In this article, Bryon Jacob and Chris Berry introduce AtomServer, their implementation of a full-fledged Atom Store based on Apache Abdera, which is now available as open source.
It is easy to think that virtualization applies only to servers. In reality the recent resurgence of the concept is also being applied to networking, storage, and application infrastructure.
In this article, Stefan Tilkov explains some of the most common anti-patterns found in applications that claim to follow a "RESTful" design and suggests ways to avoid them.
In this article, Adrien Louis and Marc Dutoo discuss the differences and relative merits of using orchestration vs. routing in a typical ESB setup, and discuss various implementation options.
Wayne Lund discusses batch processing, Spring Batch objectives and features, scenarios for usage, Spring Batch architecture, scaling, example code, failures and retrying, and the future roadmap.
Developer Jay Fields draws on his experiences as a ThoughtWorks consultant to describe effective user story estimation techniques.
11 comments
Reply