Keeping CruiseControl DRY

I recently set up CruiseControl.Net to build a number of VB applications. This post describes how I kept the CC configuration DRY (Don't Repeat Yourself), whilst allowing more applications to be easily added and reported on.

My initial set up consisted of a single project that built a set of applications defined by a text file. Whilst this made adding a new application easy, it had a number of problems:

1. Any source control change caused all apps to be rebuilt.
2. The reporting was not at the application level - if one failed to build, it showed up as all had failed.

Version two led to a separate project for each application, but this quickly became messy, as the same elements (e.g. filtertriggers, source control details) were repeated time and time again. Also, editing one project configuration would cause all projects to be rebuilt, as the one file contained all configurations.

This led to version three, which stayed DRY thanks to the use of DTD entities to separate out:

1. Duplicate elements.
2. Projects into separate config files.

Although each project was now defined in a separate config file, it could reuse the entities defined in the main ccnet.config file, thus staying DRY. Adding a new project was still simple, as it just took two steps:

1. Create a modified copy of an existing project sub-config file.
2. Modify the main ccnet.config file so it references the new sub-config file.
   

An alternative approach to this is to use CI Factory. Whilst this does streamline the setup of CruiseControl.Net, I found that once this was done, adding new projects (as above) was easy.

Testing CI Factory did have its benefits though. It led me to consider splitting the Cruise Control service into multiple services, so as to separate the main ccnet.config file into one per group of applications. This may well provide performance gains, as well as remove the problem of changes to one project config causes all to be rebuilt.

Watch this space!