Posted by johnsmart
on April 13, 2009 at 6:10 PM PDT
This case study is the second of an 8-part blog series about why so many developers adopt continuous integration , and originally published on the Atlassian blogs . It naturally has a bit of a Bamboo slant to it (if you look close enough, you can even see the odd panda), but the issues discussed apply to any team trying to adopt modern development practices, no matter what CI tool is used.
Claudia and Hans work together on a development team in Frankfort writing internal web applications for a large multi-national. While they were working on the same module, their work habits varied dramatically. Getting aligned on how they do their work was critical from transforming from a mediocre team to a high octane development team .
Claudia adopted the habit of developing in small units of work, ensuring that they are fully working within their limited scope, and committing her changes. She began using a 'Test-Driven Development ' development approach, so the code changes she makes are always accompanied by a set of new or updated test cases. Before committing her changes, she would integrate any changes that have been made by other developers since her last commit. Since she commits her changes several times a day, this integration work is usually limited to a small number of changes, and if there is a conflict, it is not difficult to figure out who made the change, and to discuss the conflict with them if required.
Hans, on the other hand, was working as a solitary developer, who preferred to work on his latest brilliantly-designed feature in isolation, for several days or weeks, until it was as complete as possible. When Hans finally integrated his changes, he would have to integrate all of his changes with weeks worth of updates from other team members - a sizeable task indeed. It was also an inefficient one, as any integration issues that were discovered were late on in the piece, and required major rework on the part of both Hans and the other developers. For example, over the last week, Claudia had made some significant changes to a core database access module that Hans happened to need for his new feature. Now Hans also updated this feature on his side, but in a totally incompatible way. Someone would have to rethink their solution, and since several other developers were already using Claudia's implementation, chances are it will be Hans.
Diagnosing the root cause
This is very much a problem of communication, rather than a technical one. If Hans had been aware of the changes that Claudia was making to the database access module, he could have taken this into account for his own changes. Since Claudia was committing regularly, all Hans really needed to do was to synchronize his code changes with the source code repository on a more regular basis. Once developers have learnt to write in small, well-tested units and commit their changes often, you need to ensure that everyone who needs to know about code changes is informed.
Making the switch to Continuous Integration
After implementing Bamboo , Hans began to get notifications every time Claudia commits some changes. Seeing the benefit, he quickly figured that it is in his interest to commit working changes as frequently as often and integrating his brilliant code with the rest of the team's was no longer a hassle. The whole team began to feel that they were coding more and refactoring less. The fast, relevant feedback on build failures helped each developer from getting blocked by a broken build. Once Hans began using Bamboo, he began to realize his build errors within minutes .
"Probably the best training course I've been on."..."Not just how to write Java code but the 'business end' - how to build, test, deploy, manage and monitor"..."One of the best and most useful courses I have attended. And they didn't even try to sell me anything!" - Coming soon to London! Get up to scratch with the latest in Java tools and best practices! Sign up on the 2009 season of the Java Power Tools Bootcamps.