[textile]I call this phenomenon "Build Blindness":

Unfortunately, if the red light is already on, we tend to ignore all the symptoms of a broken build because, after all, it's already broken. If the red light is on for more than an hour, build-is-broken becomes the natural state of affairs. from Agitar's Build Failures Policy on DeveloperTesting.com

I was inspired by the usability phenomenon of "banner blindness":http://en.wikipedia.org/wiki/Banner_blindness. Although different in many ways, Build Blindness can also result from a form of conditioning. The longer the build stays red, the less likely you will notice it's red. Agitar's policy document addresses this by suggesting specific steps to getting it green again, even if it requires a necessary compromise. One company I visited a while back had red builds that spanned weeks. No one seemed to notice (or be bothered) that it was red after while... it became the norm. This is something to avoid and I generally recommend positive reinforcement through monthly awards for the person with the lowest broken-build to check-in ratio and "fastest fixer" to avoid this (or turn it around). A leaderboard can be shown/commented on at the end of the daily stand-up... but just for a little fun... I wouldn't recommend using it as a stick to hit people with.

I’m going to invent a new term “Risk-based continuous integration” am I? I believe that practice is not so widely used, or at least not formalized. I hope to hear from You if anyone openly practice something similar. Any comments, argues and even attacks are also welcome. I plan to blog technical details of the practice, but hope to receive some feedback to understand level of detailed I should provide. Meanwhile I will try to describe the term in general.

QuickBuild is a cross-platform build automation and management server which helps continuous integration or nightly builds. Besides the ability to automate your builds, QuickBuild puts extra emphasis on build management so that your QA/release builds can be generated and managed in a simple and efficient way. Configuration, monitoring, and access to build artifacts are all done through an intuitive web interface. Your development and testing team will have a central area to access the build information.

PMEase announces the release of QuickBuild 1.0, the professional version of the open source build server, Luntbuild. Besides being a decent build automation and continuous integration server, it puts extra emphasis on build management. Some feature highlights:

1. Powerful but easy to use interface. QuickBuild's web interface has been greatly improved compared to Luntbuild. You are able to control behavior of QuickBuild through OGNL expression. Typical OGNL expressions are predefined, and you only need to choose proper expression from a context sensitive menu.

At the end of January CruiseControl 2.4 was released. Among all the new features and bug fixes one of the most interesting to me is the idea of using plugin preconfiguration to create template projects. By coincidence over the last few weeks Kevin has been doing major surgery on our build system to make everything more standardized and logical, so it turned out to be a good time for us to try out this template project idea of ourselves.

Read the full blog entry

The issue of test progress invisibility is one that I'm battling with for several years. This time I will point out absence of the specific practices (two of them) that I believe become necessary in the light of multi-layer architectures and agile development methodologies (iterative life-cycle).
I don't have a goal to suggest the best solution, only to demonstrate that we probably need to solve that.

Monitor your CruiseControl buld status in the Firefox status bar.

At first glance, building and deploying applications seem simple enough. But in fact, difficult releases without any confidence or processes backing them are very common. Integration and management of a new deployment can be laborious and fraught with risk. So as team size and volume of projects grow, management becomes more difficult and risk more pronounced.

This book is a guide to the implementation of good processes in a .NET environment. Author Marc Holmes focuses on actual implementation, and details patterns and anti-patterns to watch out for. He also provides a practical and in-depth look at NAnt and CruiseControl.NET, and solutions to common problem scenarios.