A collection of "Best Practices" for users of CruiseControl

Please add your favorite! Or dispute one of these!

The most reliable builds will be 'clean builds', which are built fully from SCC
Set up a different CC project for each maintenence branch you create
Read Mike Clark's book Pragmatic Project Automation http://www.pragmaticprogrammer.com/sk/auto/
Set up email notifications to ALL developers, so that everyone on the team has his pulse on the projects' current status
Take steps to ensure failures are reported as soon as possible. (I.e. It may be appropriate to run a limited set of "sniff tests" before the full suite.)
Write CC projects for your maintenance tasks, such as cleanup operations to avoid disk full problems.

Inspiration:

Eric Richard sent me an email asking whether I knew of a "Best Practices" document. I knew of none, so I thought this would be a good venue to collect one-liners from the community. Please add what you can. thanks.

Best practices for using CruiseControl with Ant

set useLogger="true" and use the antscript attribute for the Ant builder

even better: declare these two attributes as plugin defaults (check the section under Plugin Registration), like this (example is for Windows):

<cruisecontrol>
  <plugin name="ant"
        uselogger="true"
        antscript="D:\Java\apache-ant-1.6.2\bin\ant.bat"/>
  <!-- rest of your config file goes here -->
</cruisecontrol>

This is possible since CruiseControl version 2.2.1.

Best practices for your build scripts

CruiseControl makes several properties available to your build script: incorporate the build label in your build artifacts (for instance in a properties file or in MANIFEST.MF) so you can always trace an artifact back to its corresponding CruiseControl build.

<manifest file="${manifest}" mode="update">
    <attribute name="Built-By" value="${user.name}" />
    <section name="common">
        <attribute name="Specification-Version" value="${label}" />
        <attribute name="Implementation-Version" value="${TIME}" />
    </section>
</manifest>

Setting up a "meta-project" to update CC automatically

We found it to be very useful to actually set up a separate CruiseControl project that watched a particular area of our source control system for changes and, if it found changes, ran a build script that copied those files into the CruiseControl directory.

What this means is that if we want to alter CruiseControl's functionality, we make the modifications to the files (e.g., config.xml), check the changes in, and wait.

A few minutes later, CC wakes up, does a build, and puts the files in place.

One of the nice features of CC is that it can hot-swap files like the config.xml file. So, when the new file gets put in place, CC notices this, re-reads it, and adjusts accordingly.

There are several benefits to this approach:

If you have multiple developers managing CC, you get all the benefits of your SCM.

Developers don't have to have access to the CC build machine in order to make changes.

If you have multiple CC environments (e.g., a test and production system), you have an easy way of sync'ing up the important files. This takes the manual process out.

The one thing that we have yet to consider is how we manage differences between our dev and production envirioments. More than likely we would just set up the production environment to watch a different config.xml file (e.g., test-config.xml). The process for a developer would then be:

Update the test-config.xml file.

Check it into source control

Let the test system do an automatic run

Once you know this is working, migrate the changes over to prod-config.xml.

Check that into source control.

Best practices come from Julian Simpson

Publish with a Publisher

Keep your dependencies to yourself

Configuring CruiseControl the CruiseControl way

Bootstrap with a BootStrapper