Over a million developers have joined DZone.

Focused Extreme Feedback With CI Information Radiators - a Case Study

DZone's Guide to

Focused Extreme Feedback With CI Information Radiators - a Case Study

· Java Zone
Free Resource

Microservices! They are everywhere, or at least, the term is. When should you use a microservice architecture? What factors should be considered when making that decision? Do the benefits outweigh the costs? Why is everyone so excited about them, anyway?  Brought to you in partnership with IBM.

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!


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/

Discover how the Watson team is further developing SDKs in Java, Node.js, Python, iOS, and Android to access these services and make programming easy. Brought to you in partnership with IBM.


Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}