Created: 17 Dec 2006
At work, we’ve embraced the concept of continuous integration and I cannot overstate the benefits. Any team which needs to deploy software builds on a monthly and weekly basis should consider having a continuous integration system. However, looking at our installation and having spent a few months supporting it, there is plenty of room for improvement.
Our continuous integration systems are based on CruiseControl. Cruise is simple to set up and simply calls ant tasks. Most of the logic in the build pipeline is expressed as ant tasks. This, I think is a good approach, but it does mean that our ant config is complex and takes a while to understand, especially for sys admins and DBAs unfamiliar with ant, who get asked to investigate build failures that may be due to envionmental issues.
Since cruise only builds one project at a time, it is necessary to maintain several instances of cruise in order to keep the time between check-in and build short. If we didn’t do that, developers working on a project may find themselves waiting on other projects to complete their builds before theirs even gets a chance to start. Multiple cruise instances are also harder to monitor; with seven instances, it is more difficult to remember where to go to check on the build status of a particular project.
While Cruise itself is simple to understand, our startup scripts for it are a little too complex for my liking. They bootstrap the cruise environment from the source repository and start various supporting processes, such as Selenium. One of the downsides of embracing cruise so thoroughly is that you might need to support several cruise instances, each with their own requirements for supporting applications, and soon there are several entirely different cruise bootstrapping scripts. This makes it harder to transfer skills between projects.
The projects produce thousands of deployable builds, documentation builds and logfiles. We keep all of these indefinitely at present, but it can’t last for ever. For starters performance starts to suffer when cruise’s monitoring webapp has to handle a large number of logfiles. We need to have some way of keeping only those things which are important to us. Build 20 from trunk, which was never deployed anywhere, is not really valuable to us. In fact, very few of the builds which are older than a few weeks are of any use. We need a way of automatically deciding which things are valuable enough to keep. Until then, we’ve got a whopping great NFS share.
I think there is perhaps a case for these problems to be solved by a single product which provides the infrastructure for continuous integration with cruisecontrol. It would: