Cruise Control

An OpenSource ContinuousIntegration wrapper for build tools such as ApacheAnt or ApacheMaven (contributed by ThoughtWorks).

Current Version: 2.1.6 (released Jun 30, 2004)

Project Website: http://cruisecontrol.sourceforge.net

Wiki: http://confluence.public.thoughtworks.org/display/CC/Home

SourceForge Project Summary: http://sourceforge.net/projects/cruisecontrol

Supported VCS systems:with several

Similar tools:

Distributions:

Debian package: http://wiki.tryphon.org/JavaWiki/CruiseControl

MartinFowler and Matt Foemmel describe CruiseControl in their paper on ContinuousIntegration

http://www.martinfowler.com/articles/continuousIntegration.html

Discussion:

The quick sketch of CruiseControl (based on hearing Martin talk about it), is that it provides a set of tools that wrap "Ant", Jakarta/ApacheTomcat's XML-based make replacement.

CruiseControl monitors the repository, waiting for check-ins. After check-in activity has quiesced, it grabs a snapshot of the repository, and starts a build. The status of the build (and any adverse events) can be monitored via the web. Java sources are compiled, .jar files are created and loaded into the application server, and unit tests are run.

Martin said that the process takes about 20 minutes (my scribbled notes say 250Kloc and a 4-processor build server), and that the convention is that developers wait until a build they trigger is complete before going home. If problems arise and can't be fixed, changes are backed out for another day.

CruiseControl looks slick. I'm looking forward to trying it out. --DaveSmith

CruiseControl 1.0 was a little rough. However, I managed to get my own build scripts up and running under CruiseControl within a day, most of which was spent waiting for GeoCrawler to come back up so I could scan the archives of the mailing lists. In the process, I revealed several flaws in my BuildProcess that would have been very nasty once we got a few more developers on our project.

The major overhead to a normal checkout-build-test cycle that CruiseControl adds is examining the source repository for recent changes. This chews up a bit of time in the cycle, but then my build machine isn't doing anything else (except when I use it for performance testing). It does incremental builds, with every nth build being a complete clean-and-build (n being a configurable number).

I actually left my ant files untouched (aside from fixing the problems I mentioned earlier) while I installed CruiseControl. I instead wrote a wrapper buildCruise.xml which calls into the main one as needed.

Overall, I found it to be a very simple and very elegant system. I'm already finding the build reports useful, and I'm the only person doing serious work on our project right now. With multiple developers, this will be very useful. -- RobertWatkins.

CruiseControl can only be useful to you if you can access your repository. If you can't access your repository you can't do much anyway...

We want CruiseControl to support as many repositories as possible, but are limited in our resources. The method for adding a new repository is semi-plugin based, and will become more so. Writing support for a new repository is fairly easy, and we will gladly assist anyone who wishes to extend CruiseControl to support a new system (especially if you plan on contributing back to the CruiseControl project). -- RobertWatkins

AeGis had the functionality CruiseControl provides for quite some time. But AeGis is a larger block, coming with its own SoftwareConfigurationManagement, featuring ChangeSet?s and other things. CruiseControl on the other hand is a smaller component which can be used SoftwareConfigurationManagement systems.

What is the major gain over having the developer trigger the build? It seems like it would simply add time from the point of check-in to the point of build and run unit tests. In the environment we had set up when we were doing XP, the developer only had to type a one character alias that would check out all the sources to the integration sand-box, set-up the database with a copy of the most recent production data, apply the database changes script, and run all the unit tests.

Is it for shops where people have a hard time remembering to build in integration after they check-in?

-- JeffBay

Jeff,

It works well in situations where the full "check-out, compile, test" cycle just takes too long. For example, a compile/test cycle takes us about 5 minutes (for a clean compile), and that's not too bad, but when you add updating the source from CVS, it takes closer to 40 minutes (don't ask why), which is too long. By getting CruiseControl to run the builds, it means we can rely less on having developers do their own updates and still know when our builds work.

Some places like to run acceptance tests over an integrated system, which almost invariably takes longer than a developer wants to spend. CruiseControl works well here. Similarly, if the full set of unit tests takes too long, developers can usually get away with running a subset if they know the full set will be run in a reasonable period of time.

You may have additional work that should be done periodically. For example, our CruiseControl build generates the javadoc on a regular basis. Developers don't do this as a rule.

Above all, CruiseControl gives you confidence that what is in the source control system really, really, really does work. Look on it as a backup to a manual process, and remember it next time you have problems integrating because the previous person forgot one file, or didn't bother checking properly. -- RobertWatkins.

That backup is especially handy if you are just getting a team going with automated testing. Then nobody has to play bad cop or mother hen. With something automated and relentless, lazy people can't escape. -- WilliamPietri

The other aspect that CruiseControl gives you is reporting. You go to one place, and you can easily see what the current status of the system is; what changes have been done recently, what tests (both unit and functional/acceptance) are passing (or failing), where you've got things deployed, and so forth. For a ProjectManager, this is very valuable information. Further more, it's not hard to extend the reports for any other information that you wish to display. -- rw

Incorporating much of the input from the last year, CruiseControl 2.0 will revolutionize ContinuousIntegration. -- PaulJulius

We hope. ;) Seriously, though, the coming changes in v2.0 will make CruiseControl a lot more flexible and extensible. If we ever finish them, of course -- RobertWatkins

Go get CruiseControl 2.0 now. I wish I could come up with a description of my feelings as catchy as "test-infected". I'm definitely infected by something. -- jmj

I've been setting up CC 2.0, and I have to say that at this point, I am very impressed. This is with CVS, I am going to work on Perforce, then deploying the system to run automated builds & work... -- ChadThompson

I have constructed a crude CC documentation wiki, with the assistance of many others, at:

http://c2.com/w4/cc/wiki.cgi?WelcomeVisitors

Has this supposed wiki been hideously spammed? -- BenTremblay

The wiki is geared to new users, hosting an updated FAQ, and providing a place to share howtos/config tips. Keeping users current with new features and fixes is a more long-term goal. Eventually, it'll all go back into CC Home at Source Forge. Thanks, Ward, for all your help. -- RandyNovick

Just wetting my feet in it.. hope to use it extensively SalimChandani?

Note from RandyNovick -- Please go to the new wiki at:

http://confluence.public.thoughtworks.org/display/CC/Home.

It sure would be nice to see the juicy parts transferred. Thanks to everyone that helped out with the pupa wiki! -- R

Our current source code repository (SourceGearVault) isn't supported by a .NET Continuous Integration tool yet. We are simply using a scheduled task (every 30 mins) on our build box. Our builds take about 20 mins to pull source, compile, test, run ncover, generate docs and reports. This seems to be working well. What advantages would there be to a Continuous Integration tool over this approach? -- JonathanCogley http://www.pimpmyfoot.com

Advantage of CruiseControl over this approach is the fact that it knows which files has been changed in the source repository between consecutive builds, and puts the list of these files on the build report (together with the author and commit remarks). So, when I get an email "Build successful", it is a single message that tells me all of the following:

10 minutes ago alexeyv has committed new revisions of Foo.java and bar.xml with comment "Foo now works with bar". Build has passed. Here are unit test report, static code analysis report and a graphical diff for the current and last revision of all committed files

And I only get these messages when somebody commits something, not every half an hour. That's all quite convenient. Given that it took me just three hours to set all this stuff up on an old P-III box with just one CPU, and it runs a 200 kLOC Java project with a lot of code-generation done during the build, I am quite happy with it.

To be fair, you can set up your scheduled build to do the same, but in my case, at least, it would definitely be longer than three hours.

By the way, you can do scheduled builds with CruiseControl, too.

-- AlexeyVerkhovsky

CategoryProject

One issue I've had with CC is running the project's ant script from the CC ant script when utilizing tools such as jCoverage (which generate a serialized object store for the report generator). My solution has been to not use the ant sub-task, but execute the project build script in the following manner:

    <exec executable="d:/Tools/ant/bin/ant.bat" dir="checkout/cctest">
      <arg line="rebuild"/>
    </exec>

Yeah, I hard code the path to ant so that I can use the version of ant I want, not the outdated one that is in the CC bundle.

The ant sub-task in CC now supports the antscript attribute, which invokes an external ant installation. This is the recommended way for invoking ant from CC (see http://cruisecontrol.sourceforge.net/main/configxml.html#ant ). The above example would become

   <ant antscript="d:/Tools/ant/bin/ant.bat" antworkingdir="checkout/cctest" target="rebuild" />

-- JoeSchmetzer?

Third-party tools to support CruiseControl.

AnyUnit VisualStudio add-in (commercial) supports ContinuousIntegration and CruiseControl since version 1.3. No more weird scripts to run your unit tests. Just run devenv.exe /build and you are done. JUnit-compatible XML output will be generated from Nunit, CppUnit and BoostTest? output.