John is an experienced consultant specialising in Enterprise Java, Web Development, and Open Source technologies, currently based in Sydney, Australia. Well known in the Java community for his many published articles, and as author of Java Power Tools and Jenkins: The Definitive Guide, and founder of the open source Thucydides Automated Acceptance Test Library project, John helps organisations to optimize their Java development processes and infrastructures and provides training and mentoring in agile development, automated testing practices, continuous integration and delivery, and open source technologies in general. John is the CEO of Wakaleo Consulting, and runs several Training Courses on open source Java development tools and best practices. John is a DZone MVB and is not an employee of DZone and has posted 125 posts at DZone. You can read more from them at their website. View Full User Profile

Focused Extreme Feedback With CI Information Radiators - a Case Study

02.24.2010
| 4229 views |
  • submit to reddit

Build Server Information radiators are an excellent, easy-to-implement way of getting people to pay attention to broken builds. But it pays to tailor them to your exact needs. This article is a short case study of how easy it is to set up an effective information radiator if you put your mind to it.

One of my clients is UBS Investment Bank in London. At UBS, they are into Agile in a big way. Rob Purcell and Gordon Weir of UBS asked me in to help out with some of their Maven, Test-Driven Development, Java coding and tooling practices. And one relatively minor item they were particularly keen on was to improve their information radiator, in order to raise awareness of broken builds. Although they had a large LCD screen displaying the TeamCity dashboard, the information displayed was too small to be very effective at any distance. So we decided to add a new one.

Now Rob's team uses TeamCity in a big way. It turns out there are quite a few cool Information Radiator plugins available for TeamCity, such as Team Piazza and Build Wall. However most of the ones I found all took the approach of green boxes for the good builds, and red for the bad. And that limits the number of builds you can effectively place on an information radiator. And UBS have many, many build jobs. They wanted something simpler: just display the failures (after all, you don't really care about the builds that work).

The information radiator also had to cope with displaying failed builds from several different TeamCity instances within the organisation.

It turns out that it's quite easy to write your own information radiator in TeamCity, without having to write your own TeamCity plugin. I based the solution on Rob Bowley's customization of the External Status Widget, which came closest to doing what I wanted.

The procedure is quite simple. There is a JSP file in your TeamCity installation called externalStatus.jsp, also known as the External Status Widget, which you will find in the TeamCity/webapps/ROOT/status directory. This particular JSP was visibly born to be hacked. In it's original form, it displays a very basic screen showing the current list of build jobs. However, it is fairly easy to modify to display just the failing builds, and with some additional information to boot.

So after a few iterations working with Rob, we came up with a version that displays the Subversion user and commit message of the failing build, and a few other useful details. You can download a slightly generalized version of the externalStatus.jsp file here. In action, it looks like this:

You also need another screen to display the build results nicely. We wrote a JSP page called failedbuilds.jsp to do this, and placed it in the TeamCity/webapps/ROOT directory, along with a nice graphical icon to show when all the builds where working (see tick.gif). One challenge came from the fact that the team has many instances of TeamCity - we wanted all of the failed builds up on the same screen, and a nice reassuring green screen displayed only when none of the build servers had any failed builds. A bit of javascript and a reassuring image did the job here. You can find the full JSP page here.

Now, when there are no failing builds on any of the TeamCity instances, it will come up with something like this:

The dashboard caused quite a sensation. It was very actively championed by management, and I often noticed people wandering pass the screen stop in their tracks and stare at it. And it served its purpose well. This is the same dashboard after two days in production:

The point of this is not to illustrate a brilliant piece of HTML/Javascript/JSP coding. Actually, it's a bit of a hack. Nevertheless, with very little effort, we put in place a solution that added real value to the development process - about 75% less broken builds after two days. Not bad for a hack!

Resources

If you want to try this out at home, here are the files you need. Don't forget to modify the faildbuilds.jsp with the URL(s) of your own TeamCity server(s):

You can view the results on an address like http://my.teamcity.server/failedbuilds.jsp.

From http://weblogs.java.net/blog/johnsmart/

Published at DZone with permission of John Ferguson Smart, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)