Page 174 -

sure that the software is built the same way each time and includes all of the necessary
files and dependencies.

One of the most important ways a software project can be automated is with a develop-
ment monitoring system. Two of the most popular ones are CruiseControl (http://
cruisecontrol.sourceforge.net) and TinderBox (http://www.mozilla.org/projects/tinderbox), both of
which are free and open source. These tools allow a project team to construct a set of tasks
to be run automatically on a schedule. These tasks include:

• Retrieving the latest build from the version control system, building it, copying it to a
folder, and reporting any build warnings or errors

• Running automated unit tests, generating a test report, and reporting critical failures
• Running automated code review tools and reporting any warnings or rule violations
• Listing any changes that have been committed and by whom, including links to code
listings for the changes

• Emailing results as text or visual reports (or sent via SMS text messages or some other
communications system)

These tasks can be configured to run on any chosen schedule. Many teams will schedule
daily builds. Some will require builds on an hourly basis (or another schedule), while oth-
ers will only require automated builds to kick off when changes are checked in. The
important aspect of this is that the team can depend on these tasks being run the same
way each time. They are kept aware of every change made to the code, and they are
always aware of the health of the current build. If code is checked in that causes the build
to break or important unit tests to fail, the team will know about it immediately and will
be able to fix the problem early on, before any other changes are made.

It is especially useful to combine the reports from a development monitoring system with
code reviews. This is an especially common practice on successful open source projects,
where every change or patch applied to the code is emailed to the developers and
reviewed before it is incorporated into a production release.

Be Careful with Existing Projects

An overeager project manager can easily sour a programming team on these tools, if the
team doesn’t see the benefits. While it’s easy for a team to migrate an existing project to a
new version control system, it is much harder to begin to build unit tests for an existing
codebase. (It’s also much more risky, since the old repository can be kept around so that
the code can be moved right back if the new version control system does not work out.)
Migrating from files stored in a folder to Subversion is trivial—just build the repository,
import the files, and rename the old folder. Migrating from an antiquated source control
system to Subversion is a little more involved, but it’s still relatively straightforward. The
simplest way to do it is to import a copy of the latest revision. This will not make previous
changes available in Subversion; however, an Internet search will usually turn up scripts

166 CHAPTER SEVEN