|
|
|
Interview with Continuous Integration author Paul Duvall
|
|
Page 1 of 3
What is CI?
What is Continuous Integration?
In defining continuous integration, most people refer to the article
that Martin Fowler and Matthew Foemmel from ThoughtWorks wrote several
years ago. In it, they refer to CI as "a fully automated and
reproducible build, including testing, that runs many times a day". I
expand on this definition and describe CI as "a process of integrating
software whenever a change is applied - this may include automated
compilation, testing, inspection, reporting, deployment, and
notification."
It's amazing how their paper has become the touchstone for defining CI even though it's been around in some form or another for awhile! Given that is not some new revolutionary tool or technique, why should I care about CI?
Because it does the dirty work for you, so you can write software
for your users and not spend time on infrastructure issues. It reduces
common risks, improves the software quality, and ensures timely
feedback. I don't know about you, but I don't like paying bills so I
use automatic bill pay. Why? Because paying my bills is a mundane,
repetitive activity that drains money from my account. I still haven't
found anything to prevent the draining of money, but at least I don't
need to do the mundane repetitive work any more. I like working on
interesting and unique problems when developing software and there is
far more in software development that is "dirty work" than you might
imagine. It is the "little things" here and there that add up to
decreased productivity and efficiency. Of course, "building the
software" is something that we must do, yet I have seen far too many
shops who haven't even automated their builds. In fact, an MIT study
conducted in 2003 indicates that only between 20-25% are even running
daily builds. There is so much more, including the execution of
regression tests, static analysis tools, SCM labeling, database
integration, notification, and deployment that can and should be
automated - and run continuously.
What are some CI products and projects? What are their associated pros or cons?
There are actually a lot of players in this space - just in the past few years. CruiseControl and CruiseControl.NET
have probably gained the most acceptance in the development community.
This is what we use at my company. It is open source and well
supported. It supports well over 20 SCM systems, supports a number of
build tools, and has a nice web reporting application to view the build
status and more. The people at ThoughtWorks originally developed it.
There is also AntHill, Beetlejuice, BuildForge, and LuntBuild
to name a few. Beetlejuice and BuildForge are commercial products.
BuildForge is an example of a tool used for large enterprise projects
that need to perform distributed builds. Also, let's not forget that
the build scripting tools, themselves, are a part of a CI solution. I
consider Ant, NAnt, Maven,
and make to be a part of this picture. Believe me, I can GO; on,
especially when you consider the integration of tools, such as
inspection and notification tools into the CI system - PMD, JDepend, and the Ambient Orb come to mind.
|
|
