Continuous Integration, as a software development practice, has really taken off in the last two years. CruiseControl is quickly becoming part of the standard toolkit that people use when they get their projects up and running. Likewise, many legacy projects - those old bears that have been lurking in the software configuration management systems for years - are starting to find their way into the automated build, test and deploy cycle managed by CruiseControl. Creative developers are coming with all sorts of intriguing ideas for making the software development lifecycle visible to those who are usually unaware. The result? Astonishment!

I remember the first time I hooked up a red, flashing light (like those used on police cars) to a CruiseControl server. I wasn't too sure how it would be received. I knew that it was going to be a bit alarming to the more than 200 developers working on the floor. About 30 minutes after installation was complete, we had our first build breakage. The Continuous Integration server sent a message over the power lines to our new ‘signal of doom’. The light started flashing and people took notice. I looked around to see heads popping up out of cubicles like urbanized prairie dogs. Nobody was scared, but everyone knew that something was wrong.

Something was wrong. The build was broken.

One of the developers had checked in some code that failed the regression tests. The application, on which the company had spent considerable time, money and effort, was now in an uncertain state. It wasn't behaving as expected. In the past, this type of bug usually wasn't discovered for months. Usually, it wasn't discovered until the System Integration Testing cycle got underway. For this project, that wasn't scheduled for another 6 months. In the past, this bug would have lingered in the code for 6 months before anyone even realized it was a problem. But now, there was a simple, red light, flashing continuously, to let everyone know there was a problem. The light had gone off only 6 minutes after the code had been committed. Notice: not 6 months...but 6 minutes!

Needless to say, the managers scurried to my cube. They wanted to know what this disruption was all about. I told them I just saved them $12,535! They looked around to figure out how.

The reason I was there was simple. Earlier that year, those same IT managers had performed a series of calculations to estimate how much it cost the department each time a bug made its way out of development, into SIT, into User Acceptance Testing, or all the way into production. For this IT shop, one bug into SIT cost them $12,605 (and you can imagine how much a bug into production would cost.) So, I did some quick math. The burn rate for the developer who introduced the bug was $70 per hour. Since the developer had already fixed the bug and committed the change, I deducted the $70 from the total and ended up with $12,535. Now, it cost them $70 (or less) to fix that one bug, instead of $12,605.

The managers were stunned. They could not believe it. I walked them through the whole process. I detailed everything that the build reengineering team had been doing, and all the hard work that had been put into automating a suite of "regression" tests. I showed them all the hard work that had gone into automating the application's deployment process; all the hard work and hardware that had gone into setting up a robust, enterprise CruiseControl environment. And all the hard work that had gone into training their people on how to write and maintain automated, reproducible build scripts. I detailed it all. Finally, they realized why all that hard work was so important. Their minds wrapped around every bug that would NOT make it out of development. Their internal calculators started to tabulate the savings. I knew we had done something good.

Over the last six years, since I co-founded CruiseControl, I have been able to personally orchestrate several of these departmental, budget-altering 'aha!' moments. I am excited to be a part of such a wonderful open source project, with a thriving community. I am proud every chance I get to commit a new feature that helps the entire CI community. I am proud to have met many of the other committers that have helped to make CruiseControl what it is today. And, I am proud to be working as the Product Manager for the upcoming CruiseControl Enterprise.

I am excited to have the opportunity to push Continuous Integration forward and to make those 'aha!' moments happen more often and with less effort. I think that CruiseControl, open source, will continue to move forward with help from the ever-growing community, and I think the CruiseControl Enterprise team will be able to contribute substantially to that community. Additionally, I am happy to have a team of developers and consultants at ThoughtWorks working with me who can tackle those really challenging issues that creep into enterprise-class CruiseControl installations.

The enterprise deployment landscape isn't simple, and probably never will be. I intend to help make CruiseControl Enterprise one of the best tools for navigating that landscape.