Irradiating the whole team

You want to check in? Is the CruiseControl build green? What you do mean, you don't know? Everybody in the project room (and ideally, those people the project room) should know what is going on with the build. Broken Continuous Integration builds mean that the project can't release working software.

So to keep the team in the loop I set up a Extreme Feedback device recently. On our present engagement the developers have been using CCtray with some custom JSP's to hook into CruiseControl (CCtray is now supported in CruiseControl 2.7.1) which worked well for keeping developers and technical people informed. Well, if they are running Windows.

What we had failed to do was involve everyone - BA's QA's, Project Managers and Business people. They all have a very real stake in the delivery of the project; and as the "heartbeat" of the peoject is the activity around the Continuous Integration system, I thought it was time to share. I wrote a Ruby application that would report on the state of the build in simple, traffic-light terms, ran on it on disused workstation with a browser. That was a few months ago.

Since then I managed to convince our Programme Manager to fund a 32-inch display to run the application on. By the time the display had been sourced and installed on the wall, the scope had crept for the application; now it is a Ruby on Rails app that displays build status on the left hand side of the screen, and cycles through several screens to display project information: Message of the Day, bug counts, burnup chart, etc.

My favourite part is the build duration chart. I used a CruiseControl publisher to invoke wget, which will perform an HTTP post to a specific URL. This pushes the timing information of each completed build to a Rails application. Then it's easy to draw a chart of the cumulative timings with Gruff.

Making information visible to an entire room is natural behaviour for systems administrators and NORAD staff. We're just borrowing a great idea.

DevOps New Zealand