adams.co.tt

A common standard for build status

15th March 2010

A common standard for build status

The advantages of using continuous integration are well known. The ability to have code built and tested regularly, hopefully with each checkin, is extremely useful, but only so if the developer is fed back that information quickly and clearly.

Most continuous integration servers provide some kind of notification functionality, which means the developer doesn’t have to go and manually check that his or her checkin has passed the build. These can take many forms, from applications that run on each developer’s machine and poll the server, to email notification, to instant messenger messages, to large screens that radiate information regarding build status to the whole team.

However, in most cases, the means by which these notifications occur is different and usually specific to the continuous integration server in question. For example Cruise, TeamCity and FinalBuilder all provide desktop notification applications, but they all interact with the server in different ways.

This becomes problematic because it means that you cannot use your notifcation application of choice with your CI server of choice. There are some very useful build radiators out there, such as BigVisibleWall. It would be extremely useful to be able to use that with TeamCity, but this is not possible. This can make it difficult to change CI server with the changing requirements of a team. For example, most projects start small. In this scenario, a quick to set up server like Hudson is ideal. It’s small and requires very little configuration to get going. But as the codebase and tests grow, the team may wish to switch to a solution that allows the use of build agents, such as Bamboo, Cruise or TeamCity. However if all the team’s build notification infrastructure will suddenly stop working, this will be a real barrier to that change.

To that end, I would suggest that some form of common build status API be used. In its simplest form, the CCTray specification provides what most build notification applications require. It’s already implemented by Cruise, CruiseControl and Hudson, and probably other CI servers. It allows users to use notification applications like BigVisibleWall, CCMenu and CCTray, and is a very simple format that is easy to write clients for:

<Projects>
<Project
name=“SvnTest”
activity=“Sleeping”
lastBuildStatus=“Exception”
lastBuildLabel=“8”
lastBuildTime=“2005-09-28T10:30:34.6362160+01:00”
nextBuildTime=“2005-10-04T14:31:52.4509248+01:00”
webUrl=“http://mrtickle/ccnet/”/>

<Project
name=“HelloWorld”
activity=“Sleeping”
lastBuildStatus=“Success”
lastBuildLabel=“13”
lastBuildTime=“2005-09-15T17:33:07.6447696+01:00”
nextBuildTime=“2005-10-04T14:31:51.7799600+01:00”
webUrl=“http://mrtickle/ccnet/”/>
</Projects>

Source

tags: ci, post
blog comments powered by Disqus