I’ve almost got something that works out of CruiseControl.Net. Once I’d hacked in some fixes for the project triggers and other stuff that didn’t work the way I wanted it to I concentrated on generating the config files that I required and testing the system.
The good news is that I now have an integration system that works, it can build, test and deploy libraries in such a way that dependent libraries and applications are rebuilt as new versions of deployed artifacts become available. The config file generator can generate files for all of the build machines that I’m currently using and builds projects per machine, per compiler and per branch so that I can have several compilers building several branches on several machines and can see what’s what from the CCTray application (it would be nice if that allowed you to group projects…).
The bad news is that CruiseControl.Net just isn’t really designed for this kind of scalability… I have lots of projects (each library consists of 4 projects (build, build tests, run tests and deploy)), my most basic server application needs 6 libraries and the exe projects, so that’s almost 30 CC.Net projects (per branch, per compiler, and (optionally) per architecture). Adding a server that doesn’t use any new libraries means 2 more projects (servers have build and test projects)…
It’s better than not having an integration system but on my old dev box which does the builds for VC6, VS2002, VS2003 and VS2005 I currently have a CC.Net server running with 190 threads which is thrashing the box with pointless busy work as it polls itself to determine if the projects need to be rebuilt. My main x64 dev box is almost as bad, it’s building for VS2005 and VS2008 for both x86 and x64 (so total projects X 4 for each branch that I want to build)… And this is with the whole system building using two queues, so there’s only ever two concurrent actions in progress (a build and a test run can run at the same time).
Still, it’s free and it has flushed out some project file configuration issues which prevented random sequences of x86 and x64 builds from working (but these probably wouldn’t have bitten real users of the code) and it’s also flushed out a race condition bug that was causing a test run to fail every so often.