Let me begin by saying that CruiseControl.NET certainly delivers on it’s core promise as a Continuous Integration server - once everything is properly configured, the system ticks over well.
However, “Once everything is properly configured” is the sticking point.
I’ve found (late 2008, early 2009) that CruiseControl.NET is poorly documented and it is difficult to find out how to do things. Worse, once you find out, the answer in most cases is to manually configure one of a myriad of XML files - and heaven help you if you break one as the diagnostics tell you almost nothing.
My key point here is this: I don’t want to set up a CI system and have it be “Bevan’s CI system”. I want the CI system to belong to the team, not to me.
There’s no point setting up a continuous integration system if everyone sees it as belonging to me - this builds in a limitation where people won’t make full use of the system unless I’m there to hand hold them.
In my mind, the continuous integration system has to belong to the team - this means that it must be accessible to everyone on the team, that anyone on the team who has a need for a regular build should be able (both in terms of permission and capability) to set things up as they need.
Having the configuration buried in a series of XML files, with no user affordance or guidance simply raises the barrier of entry too high.
CruiseControl.NET needs to lower the barrier of entry as low as possible. To achieve this, CruiseControl.NET needs a serious UI makeover, one that provides a full configuration UI so that people rarely, if ever, need to resort to hand mutilation of XML files.
Comments
blog comments powered by Disqus