Information radiators are one of the core building blocks of any agile environment, you should never hide or feel the need to hide anything you’re doing. Information radiators encourage (or at least they should) a feeling of pride in teams allowing them to show off what they’re doing. They should be freely accessible for everyone to see what’s going on and share in the joy of what’s being created. They also encourage (if used correctly) good behaviour in teams: no-one likes public shame.
In line with this and following on my post of setting up a Continuous Integration environment with Hudson and .NET I decided to go about putting in place an effective Build Dashboard. For me an effective dashboard (or information radiator) is one that gives as much relevant information as possible with the least amount of effort to read. So, lots of flash, none of the boring stuff, easily accessible by as many people as possible.
Of the various methods out there I went for displaying information on a big screen, this gives you both the high visibility and the information all in one. Some of the other methods like lights and sound are nice, but limited in some way.
In our environment Hudson is our CI tool of choice and it has a pretty nice built in default dashboard:
.. which works great at short distance but not really great at long distance. There are also lot of plugins available to customize this dashboard and make it better viewable but none of them appealed to me as fit for purpose.
Looking around I finally found a post by Fabio Pereira that looked promising. Essentially the monitor is an HTML page with backing style sheet and javascript to extract information from your CI Server (like Hudson, using it’s API facilities). The standard one that he supplies in his blog looks like this (sorry for the bad quality of the pic) (when implemented in our environment):
For each project is should the following:
- Name of project.
- Build result (green for passed, red for failed, orange for building).
- Time since last build.
- How long the last build took.
I made the following modifications:
- Added in a unit test coverage percentage (with colors indicating above/below agreed minimum).
- Changed the font size based on how long ago the project last built. In other words, old projects shrink, lots of tiny font projects = not much being done.
- Added a picture displaying who checked in code that triggered the build. Encourage responsibility for what’s done.
- Added a color (yellow) to indicate an unstable (but not failed) build.
And now it looks like this:
Also, it’s strategically located:
In the end it turned out to be pretty effective. It was fully automated, highly visible, everyone (team and customer) had access to it and could see it clearly and understand at a glance what was happening on each project. Broken builds and low unit test coverage are quickly exposed and no activity on projects can be seen quite clearly. Only thing I need to figure out now is how not to burn the image into the screen (no screensaver 
) but I guess if there’s enough churn on a project that shouldn’t happen, more motivation to continuously check in and build I guess…
As usual I’m always looking for ways to improve so feedback is more than welcome. Can you think of ways to improve what I’ve done?
In part 2 of this I’ll got through the code behind this dashboard and try and explain it a little so that implementing it becomes easier, I’ll also attach the actual code (not pretty, but effective nevertheless 🙂 )
Leave a Reply