C H A P T E R 20
■ ■ ■
Continuous Integration
In previous chapters, you’ve seen a plethora of tools that are designed to support a well-managed
project. Unit testing, documentation, build, and version control are all fantastically useful. But tools, and
testing in particular, can be bothersome.
Even if your tests only take a few minutes to run, you’re often too focused on coding to bother with
them. Not only that, but you have clients and colleagues waiting for new features. The temptation to
keep on coding is always there. But bugs are much easier to fix close to the time they are hatched. That’s
because you’re more likely to know which change caused the problem, and better able to come up with a
quick fix.
In this chapter, I introduce Continuous Integration, a practice that automates test and build, and
brings together the tools and techniques you’ve encountered in recent chapters.
This chapter will cover
- Defining Continuous Integration
- Preparing a project for CI
- Looking at CruiseControl: a CI server
- Specializing CruiseControl for PHP with phpUnderControl
- Customizing CruiseControl
What Is Continuous Integration?
In the bad old days, integration was something you did after you’d finished the fun stuff. It was also
the stage at which you realized how much work you still had to do. Integration is the process by which all
the parts of your project are bundled up into packages that can be shipped and deployed. It’s not
glamorous, and it’s actually hard.
Integration is tied up also with QA. You can’t ship a product if it isn’t fit for purpose. That means
tests. Lots of tests. If you haven’t been testing much prior to the integration stage, it probably also means
nasty surprises. Lots of them.
You know from Chapter 18 that it’s best practice to test early and often. You know from Chapters 15
and 19 that you should design with deployment in mind right from the start. Most of us accept that this
is the ideal, but how often does the reality match up?
If you practice test-oriented development (a term I prefer to test-first development, because it better
reflects the reality of most good projects I’ve seen), then the writing of tests is less hard than you might
think. After all, you write tests as you code anyway. Every time you develop a component, you create
code fragments, perhaps at the bottom of the class file, that instantiate objects, call their methods. If you