Information Technology Reference
In-Depth Information
Is It Continuous Compilation or Continuous Integration?
I've worked with a number of organizations on implementing CI,
and on several occasions I've heard the reply, “Yes, we do CI.” Of
course, I think, “Great!” and then ask a few questions. How much
code coverage do you have with your tests? How long does it take
to run your builds? What is your average code complexity? How
much code duplication do you have? Are you labeling your builds
in your version control repository? Where do you store your
deployed software?
I discover that what they've been doing all along is more like a
“continuous compilation,” in which they've set up a tool like Cruise-
Control to poll their version control repository (e.g., CVS) for
changes. When it detects changes, it retrieves the source code
from CVS, compiles the code, and sends an e-mail if anything
goes wrong. Automatically compiling the software system on a
separate machine is better than nothing at all, but doing that isn't
going to provide all of the benefits of a full-featured CI system.
so far. Often, attempting to throw everything into a CI system immedi-
ately can be a bad move, just like refactoring a lot of code at once isn't
the best approach when writing software. Get it to work first, get
developers using it, and then add other automated processes as needed
based on the project risks.
It is best to implement CI early in the project. Although possible, it is
more difficult to implement CI late in a project, as people will be under
pressure and more likely to resist change. If you do implement CI later
in a project, it is especially important to start small and add more as
time permits.
There are different approaches to setting up the CI system. Though
you eventually want a build to run on every change to the system, you
