Product Development in Brisbane

Continuous Integration isn’t rocket science…

After hearing Aslak talk about how great Damage Control is, and how it builds on some of the lessons learnt from Cruise Control, I thought I would take a look for myself, and get a feel for what the features are, and seeing what it offers over Cruise.

CruiseControl is not exactly the cleanest piece of code that is out there. The are large pieces of it that are only ever run through the unit tests, proving that good tests coverage doesn’t enforce good code. The configuration and setup of it is also harder than it needs to be. At the end of the day the responsiblities for a Continuous Integration tool are simple:

1) Check the version control system for updates (I think it is important to do this without changing the version control system, even if it means polling it every couple of minutes).
   builds should still happen after every commit (with the configurable lag time).
2) Call out to a build program (simple support for ant is nice) capturing the result of the build, as well as messages.
3) if the result of 2 is a success, send messages to the appropriate targets (e-mail support is crucial, anything else is nice).
4) on a failure send messages to the appropriate targets.

In order to support the above process there would need to be a simple config file perhaps using YAML. Ideally the configuration should be decoupled enough from the rest of the application, that this could be put into XML or properties as desired.

Obvious targets for 3, and 4 are e-mail messages (putting the results in the message would be useful), and a project website. The possibilities for others would be: IRC/Messanger/SMTP/SMS/Telephone Messages/etc etc etc…..

The configuration format should be simple enough that a front end for configuration should not be required. A page for restarting the build might be nice, but under normal running coniditions this wouldn’t be required.

Most of what is described here is met by Damage Control. The thing that I don’t like about Damage Control is that it seems to almost be overengineered. It is noblely doing alot of things in elegant ways, but in doing so, I think it is getting away from what is most useful for the typical internal development team. The need is for something that anyone could download, edit a simple config file, and have it just work. Any more magic should be hidden from the casual user, but possible to implement by the more advanced one.

If anyone has a free one of these, or wants to build one let me know :).

One Response to “Continuous Integration isn’t rocket science…”

  1. Jon Tirsen Says:

    Yeah, DamageControl is still kind of rouch around the edges. Give it a swirl in 6 months or something and you’ll get a completely different experience.

    I’m not sure I would say DamageControl is overengineered though. On the contrary, it’s core design is almost too simple: there is one central hub for messages, you can put a message in there, and you can receive messages from it. This is the reason why it’s still so hard to configure, we don’t have any design what-so-ever for configuration and stuff. That’ll come though, but one thing at a time.

Leave a Reply