Enterprise Continous Integration

Mike Roberts, one of the lead devs of the CruiseControl.NET project, has just published a paper on Enterprise Continous Integration.

Mike is addressing a very importan issue of Continous Integration and automated build processes, namely "What to do when the build takes too much time?". Integration time was one of the hot potatoes at last years BoF with James Newkirk at TechEd. Mike outlines a solution for splitting up those 10 min -> 12hrs (!?!!?) builds.

We have practiced a lightweight solution of Mikes approach for a good while. In our CI projects we don't use the file system monitor. We've included extended targets for release builds of our "root" projects. When a project is built in release and other projects have dependancies to it, the project deploys the new components directly into the sourcecontrol of the dependant projects. This will automatically trigger a build just as any other change.

Of course, this is not as robust as Mikes approach, but very quick to implement with only some simple checkout/checkin operations.

I've talking a lot about CI for .NET developers these days, related to the upcoming release of Team System and what we can do today with tools like CCNET. I like to address two issues before getting into the details of CI.

Because most development projects that are looking into CI has an existing codebase it's important to acknowledge the physics of Software Reengineering in such a change process. Software Reengineering is the art of regaining control of your codebase by reverse engineering, refactoring and forward engineer your application to improve its evolvability.

Software reengineering is often about introducing improved structure (architecture) and improved platform (technology) at the same time to revitalize legacy software.

The point here (to make it shortish) is that if you're looking at getting into CI, and your software is a potential "2hrs builder", then improved architecture should probably come before new platform. The entire fuzz about Service Oriented Architecture the past years is all about decoupling systems and applications into loosely coupled services, without the need of binary dependencies.

ECI is a necessity, and I'm looking forward to explore how Team Foundation Server is addressing this aswell as following Mikes lead for now, but the most important thing is to keep the services in the architecture managable and loosely coupled. It's easier to publish a new (versioned) WSDL file than dealing with binary dependencies.

Finally: Great work Mike, it's truly appreciated!