What builds are set up on my Continuous Integration tool

On projects that I see, most are using a Continuous Integration tool. Many, however, still do not use those tools to their fullest. Here is what I typically set up on projects that I have control on.
First, let me make this clear: it is not a bad sign if all this is not in place. However, all team members should always try to make the situation better. Incremental improvements are key.

All CI tools should allow this configuration. If you don’t have one, try Hudson, a powerful tool that remains surprisingly easy to use.

For the same project, I usually have 3 builds set up.

• a quick build for unit tests. It should run as often as possible, typically after each check in.

If your version control tool does not support atomic check ins, you’ll need to set a quiet period: a minimum period of inactivity on the version control tool before a build starts. This ensures that the CI tool does not start a build until all the files for a particular feature are checked in. Consider switching to tools such as Subversion (free) or Perforce (commercial), which do support atomic check ins.
This build should run only unit tests, and be as fast as possible. Jeffrey Fredrick recommends that it should be fast enough to run 100 assertions per second. Yes, this is a serious constraint. In particular, it means that tests that need to access external systems cannot be considered unit tests (move them to the integration/functional tests build).

Usually, such a build lasts 10-15 mins. Any developper should be able to run it easily on his own machine.

• a slowish build for functional testing. You might want to run it only after the build for unit tests (Hudson has a feature that lets you chain builds), so it will only be built when the unit tests pass, reducing the number of false warnings.

Run all the tests you can in this. Functional tests, GUI tests, etc. If you use a tool like Fitnesse, consider configuring your tests so that they break the build when regression tests (from previous iterations) break, but only show a warning for features developed in the current iteration.

Since this build typically last an hour or so, it will by necessity be run much less often than the build for unit tests.

It is also important that developers can run this build on their own machines.

• a less frequent build for technical documentation, such as the Maven site for your project. I often set this up to run only during at the middle of the night, as it is often resource-hungry (many site plugins for Maven actually require the unit tests to be run, and often those tests get run once for each plugin!). If you have plenty of CPUs available, then it is (slightly) better to run that build as a follow up to the function tests build.

If, like me, you are interested in these aspects, consider participating to CITCON, the conference on Continuous Integration & Testing. This, and more, is typically what is being discussed there. The next edition is in Denver, April 4th & 5th. There will be one in Melbourne and one in Amsterdam later this year. And it’s all free!