Find it here: http://cradiator.codeplex.com/

I’m not doubting that making embarrassing indicators more public can contribute to the motivation for keeping builds clean, but if you have to rely on being shamed into keeping builds clean then there’s a deeper root cause to address that is still there, lurking, waiting to cause another problem, or presently causing other problems that should be solved but aren’t embarrassing enough to address.

It’s not wishful thinking it’s *fact*. Personally I’ll take real evidence over hypothetical musing anyday of the week.

For example, first thing this morning many people noticed there were way too many broken builds on the board and there were various discussion about them. Everyone is now aware of the context behind these broken builds (even if they don’t affect them) and what needs to be done. These conversations simply would not have taken place if the only indicator was a little red blob on their taskbar.

It’s not just me that says it. Many people have noted the impact of the monitors and are really pleased with them. I can’t see how you can say this is wishful thinking!

I would encourage anyone reading this to ignore Scott and give it a go as it has had a fantastic impact in my organisation. Some advice though – I would advise only having information that is relevant. Why do you need to know if a build is passing for example? Use them like Toyota would bells or lights when there is a problem on the production line.

Good post.

Too bad TeamCity doesn’t just push the standard CruiseControl XML like the rest of the CI world does. For instance, Hudson pushes the CC XML format in addition to its own native format.

There are so many tools that understand the CC format, its an oversight for JetBrains to leave it out.

That’s wishful thinking. Given the right context, a broken build displayed in a grid on a tv screen is just as easily ignored – especially the greater number of builds displayed. It’s the predisposition to ignore broken builds that makes this happen, not the predominance of indicators.

Yes: start thinking like a tester – automation isn’t always the answer.

Perfectly stable browser automation under CI is a fool’s errand. Closing the last mile gap is more expensive and less useful than having better-integrated testers and testing into the development process.

That said, I use explicit “done” markers in the html to prove that an ajax request is complete. I haven’t found more stable means.

Putting the failing builds on a monitor on the wall has had a massive effect. It is probably the single most effective change we have made (and one that took very little effort). Everyone who walks through the office can see the monitors including managers who don’t have TeamCity on their taskbar. No one wants to be on there for long. It has also brought the developers together as a larger team as all teams failing builds are on one monitor and it is everyone’s responsibility to try to keep it clear.

A little red ball on the task bar is easy to ignore. A bog red bar on a monitor everyone can see is not.