Skip to main content

CI Adoption stories part 1 - Johan's Outsourcing Blues

Posted by johnsmart on April 7, 2009 at 11:53 AM PDT

This case study is the first of an 8-part blog series about why so many developers adopt continuous integration, and originally published on the Atlassian blogs.


Johan is a project manager who works on internal corporate web applications for an IT shop in Frankfurt, Germany. He has a team of 10 developers, testers and BAs based in Germany, as well as an offshore team of similar size based in Bangalore, India. The project is not without hitches - co-ordinating work between teams in different parts of the world requires a much bigger overhead in time and effort than Johan's organization had initially thought. The offshore approach was imposed on the German development team from above, and is unpopular with many of the local developers who view it as a threat to their own jobs. Johan knows that this is not insurmountable, but that the two teams need to gel better before they can work together effectively.

The language barriers also make things difficult. Although all the team members can get by with written English, many are not confident with spoken English, BCS1.pngmaking communication by telephone or teleconference difficult. The two teams work in different time zones, which doesn't make things any easier. In several cases, developers on one team have committed end-of-day changes that broke the build process. One time for example, Hans, a developer in the Frankfurt team, committed his latest changes at 5 PM Frankfurt time, but forgot to include a key new class. When the Indian team got to their office 8 hours later and checked out the updates, they were stuck for most of the day with a project that would not compile. This sort of incident does little to foster good will and harmony between the teams.

One Step Forward... Two steps back

Nor do code conflicts where a developer over-writes the changes made by another, which has happened a few times as well. For example, there was the time Jagath, a young developer on the Indian team, wanted to update his code before committing his changes. Doing this, he noticed some conflicting changes coming from the Frankfurt developers. BCS1a.jpgDeciding to fix what appeared to be an obvious bug, Jagath over-wrote these changes with his own. However, the changes coming from Frankfurt weren't actually bugs - it was part of the implementation of another feature that Hans had been working on. Naturally, Hans was less than impressed.

This sort of thing is symptomatic of a broader communication problem - the developers on both teams are largely unaware of work done outside their own IDE until it is too late. There is little communication between team members on why particular changes are being made, and little opportunity to give feedback on these changes. This inevitably makes integrating the work done by each time more difficult, and can also lead to hard-to-find issues caused by misunderstood APIs or architectures.

Driving for team improvement

Johan needed a way to encourage his developers across both teams to collaborate more closely. He knew that communication is a key aspect of any development project, and even more so in the case of separated teams, so he needed to ensure that the communication channels between team members are open and being actively used. Everyone needed to know when changes are being made to the code, what they are, and whether they are compatible with their own work. Team members needed to be encouraged to communicate more spontaneously about code changes and technical solutions, and about potential code conflicts and integration issues.

Adopting Continuous Integration

Johan decided to attack his teams communication issues by adopting Bamboo. Since written English represents a lower communication barrier than spoken English, Johan has installed, and encouraged the use of, an internal IM server. All code commits and build results are sent to all team members by IM.

Thumbnail image for bamboo icon.pngThe move to Continuous Integration made a significant difference because developers would get back notified of the success of their build changes within 15 minutes of each commit. It has also increased awareness about what changes other developers are making to the code, and Johan has noticed an increased number of spontaneous IM discussions about coding issues between the team members. The overall effect has been to reduce the amount of time wasted due to cascading problems with broken builds.


"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.