If you’re a computer programmer and you work on a team that uses some sort of agile methodology you most likely have a build screen in your office. The build screen, the most sacred piece of office equipment - with the possible exception of the coffee machine - should be the first thing you look at when you come to the office in the morning, the first thing you look at whenever you take your eyes off your computer screen and the last thing you look at when you leave the office in the afternoon. And if the build screen shows you that something is amiss, you should sit back down and get it fixed1.
Because of this, the build screen should be positioned somewhere in the office where everyone - including management, the customer, the janitor and the janitor’s second cousin - can see it without too much effort. Cramming it in a corner where only one developer can see the screen totally ruins the agile feng shui of the room. The build screen is important because the information displayed tells you if there are something rotten in your code base. If it is, it should be a priority to get it fixed. Remember that test which started failing last week that no one gave a crap about? Well, the reason why it failed made its way all the way through QA and now you have a priority level A bug rattling around in production: 10 minutes to respond to the customer’s bug ticket, 30 minutes to come up with a work around and 8 hours to get a fully tested bug fix deployed. The only problem is that the customer requires that every deployment, no matter the size, goes through the 250 pages QA process. Looks like someone will have to burn some of that midnight oil. Why, oh, why, didn’t you just fix everything when the build screen reported the error last week?
The morale of the story - there’s always one - is to get a good build screen for your CI server and actually use it. If you’re using Jenkins, I would shamelessly recommend the Wall Display Plugin, an open source project that I’ve spent a few hours contributing to.
The screenshot I borrowed from the plugin site doesn’t show everything the build screen can do. If you’re red/green color blind, there’s a theme you can use (green is replaced by blue), and the name of whoever was responsible for a build failing is displayed if that ever happens (it does). It should be an embarrassment every time your name shows up, either as the one who committed code that broke the build or made the tests fail.
The plugin can be installed from Jenkins’ plugin manager, and configured from Manage Jenkins -> Configure System. Have fun!
Of course, as with any other theory, this might not be exactly how it works in real life all the time, but if we can at least pretend that we actually use the build screen for something, that’s a start. ↩︎
vegard at vegard dot netwith your input. You can also use any of the other points of contact listed on the About page.
Is there anything that makes this one better over the "Status Monitor"?
I just stumbled over the same issue. In my case it turned out that the wrong version (6.2.0) of the plugin was loaded via jenkins.
I installed version 6.17.0 manually and this solved the problem (look here for a pointer to the procedure and location