Incremental integration

Integration of code and committing code into the repository is done every few hours.  Code changes are theoretically never held on for more than a day.  This is one of the most inefficient practices that I have ever encountered.

The problem with this practice is that it consumes too much of the development team’s time.  For example, a developer in the morning pulls down the code from the repository and does a build, runs the unit tests, and then runs the acceptance tests.  Assume this takes 65 minutes.  A few changes are made, and then does another build, runs the unit tests, and then runs the acceptance tests, which takes another 65 minutes.  Assuming that the tests pass, the developer then has to use a merge tool to determine if any developers have checked in code that needs to be integrated.  If there is new code to be integrated, then the whole cycle repeats itself and continues until the code can be checked in.

On the extreme programming project I worked on, it was not uncommon for this cycle to repeat itself several times as developers checked in code on top of each other.  At times, it got so bad that I had to resort to locking files that I wanted to check in so that no one else could check in on top of me.  Not only is this practice very inefficient, it is also quite frustrating and leads to early burnout.

A dedicated build-computer is used to build the system.  The build-computer is set up to automatically detect code changes and a new build is launched when this occurs.  Theoretically, if the team follows the proper build procedure, the build will never break.  If the build does break, then all activity must stop until the build is fixed.  The idea here is that if a developer builds the system on his computer, runs the unit and acceptance tests, and then uses the merge tool before checking the code into the repository, the build should theoretically never fail to build successfully.

However, on the extreme programming project I worked on, every developer on the team broke the build at least once, including myself.  Most developers broke the build more than once.  One time the system was down for over 3 days.  Breaking the build means that the code compiles or links with errors.   When the build breaks, no one can check code in or out and the project grinds to a halt until the build is fixed.

There is nothing wrong with an automated build-computer that builds the system every time new code is checked in.  The problem is with assigning small tasks instead of larger ones, assigning tasks that require developers to make changes to the same classes, and expecting developers to check code in every few hours instead of at the end of a few days or few weeks.  All of this means that developers will be wasting huge amounts of time with the build / test cycle, checking in on top of each other, and merging / redoing the build cycle until they finally manage to check their code in.

If the development team should decide to use an automated build that runs the acceptance tests, then it is important to continue with the next task and not wait to see if it was a good build or not.

Prev          Next          Back to problems with agile practices topic

Copyright 2011 by Robert G. Bryan

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s