CHAPTER 20 ■ OBJECTS, PATTERNS, PRACTICE
Continuous Integration
It is not enough to be able to test and build a project; you have do it all the time. This becomes
increasingly important as a project grows in complexity and you manage multiple branches. You should
build and test the stable branch from which you make minor bug fix releases, an experimental
development branch or two, and your main trunk. If you were to try to do all that manually, even with
the aid of build and test tools, you'd never get around to any coding. Of course, all coders hate that, so
build and testing inevitably get skimped on.
In chapter 20 I looked at Continuous Integration, a practice and a set of tools that automate the build
and test processes as much as possible.
What I Missed
A few tools I have had to omit from this book due to time and space constraints are, nonetheless,
supremely useful for any project.
Perhaps foremost among these is Bugzilla. Its name should suggest two things to you. First, it is a
tool concerned with bug tracking. Second, it is part of the Mozilla project.
Like Subversion, Bugzilla is one of those productivity tools that, once you have tried it on a project,
you cannot imagine not using. Bugzilla is available for download from http://www.bugzilla.org.
It is designed to allow users to report problems with a project, but in my experience it is just as often
used as a means of describing required features and allocating their implementation to team members.
You can get a snapshot of open bugs at any time, narrowing the search according to product, bug
owner, version number, and priority. Each bug has its own page, in which you can discuss any ongoing
issues. Discussion entries and changes in bug status can be copied by mail to team members, so it’s easy
to keep an eye on things without going to the Bugzilla URL all the time.
Trust me. You want Bugzilla in your life.
Every serious project needs at least one mailing list so that users can be kept informed of changes
and usage issues, and developers can discuss architecture and allocation of resources. My favorite
mailing list software is Mailman (http://www.gnu.org/software/mailman/), which is free, relatively easy
to install, and highly configurable. If you don’t want to install your own mailing list software, however,
there are plenty of sites that allow you to run mailing lists or newsgroups for free.
Although inline documentation is important, projects also generate a broiling heap of written
material. This includes usage instructions, consultation on future directions, client assets, meeting
minutes, and party announcements. During the lifetime of a project, such materials are very fluid, and a
mechanism is often needed to allow people to collaborate in their evolution.
A wiki (wiki is apparently Hawaiian for “very fast”) is the perfect tool for creating collaborative webs
of hyperlinked documents. Pages can be created or edited at the click of a button, and hyperlinks are
automatically generated for words that match page names. Wiki is another one of those tools that seems
so simple, essential, and obvious that you are sure you probably had the idea first but just didn’t get
around to doing anything about it. There are a number of wikis to choose from. I have had good
experience with one called Foswiki, which is available for download from http://foswiki.org/. Foswiki
is written in Perl. Naturally, there are wiki applications written in PHP. Notable among them are
PhpWiki, which can be downloaded from http://phpwiki.sourceforge.net, and DokuWiki, which you
can find at http://wiki.splitbrain.org/wiki:dokuwiki.
Summary
In this chapter I wrapped things up, revisiting the core topics that make up the book. Although I haven’t
tackled any concrete issues such as individual patterns or object functions here, this chapter should
serve as a reasonable summary of this book’s concerns.