I'm Michael Brunton-Spall and I'm one of the developers here at theguardian.com.
I was privileged recently to be allowed to write a guest post on build-doctor.com about our experience of writing a build radiator. The post generally assumes that you know how agile development works, and what a build radiator is, so I thought you might appreciate knowing some more about the internals of development here at theguardian.com.
One of our agile techniques at theguardian.com is to have a central build machine. That means that the only way that the code that I write can get out into our production servers is to get copied to a central machine (using something called source control) and that central machine runs all the processes that turn my code into the program that actually serves the website.
This provides us with an environment that does the build in a repeatable, consistent way. But sometimes I might "check in" code that doesn't actually work. Because we write tests as we go, this shouldn't happen, but because my code might interact with code someone else has written it ends up happening a few times a day. We need a way to find out that the building machine has failed to build the code. The developers have access to that information via a program called ccTray. But we felt it was important to be able to get that information out to everybody working on the project in an easy way.
The thing that gets that information out is called a build radiator, because it radiates the information about the build to the room. We use a large widescreen tv, and a custom application that rotates the display through a number of different information views. You can find more details at the post over at the build doctor.
