Setting Up CruiseControl.NET
By Thomas Krehbiel
· Krehbiel Tech · Tuesday, Apr 21, 2009, 8:59 PM · 366 words
As an experiment, I’ve been working on setting up CruiseControl.NET at work, but I’ve run into a few annoying snags.
First of all, continuous integration rocks. There is no doubt it is a handy tool for maintaining source code integrity. I find it’s especially useful for code that is shared among many projects.
Now for the snags. We have some “common” class libraries that are referenced by several application projects. In the source tree, the common libraries are in one path, while the application projects are in entirely different paths. This seems like it would be a pretty common scenario, but it doesn’t look to be supported by CruiseControl.NET, since you can only fetch a single SourceSafe project folder to build.
I see only two solutions: Fetch the entire source tree from the root level, which would be time-consuming and resource-intensive, or use the SourceSafe sharing features to maintain copies of the common class libraries in sub-folders within the application projects.
I picked the latter solution. I’m not fond of sharing code inside SourceSafe because my experience has been that it’s kind of slow and clunky. And it adds an extra layer of complexity to the source repository, in that whoever manages the repository in the future must realize that some of the projects are shared. But it’s better than bringing down the whole repository for each project I want to build.
We also have a disturbing number of Visual Studio 2003 projects hanging around, and I'm having a hard time setting them up in CruiseControl.NET. The "msbuild" task obviously doesn't work, since that's a Visual Studio 2005 feature. I've had some success with the more basic "devenv" task, but it's hit or miss – sometimes I can't get the build to find all the references it needs (like Microsoft Enterprise Library).
The only other solution I’ve found for those old projects is to find the time to build NAnt scripts for them, or find the time to upgrade them to Visual Studio 2005. Time is in short supply, so the older projects probably aren’t going to be very well represented in the automated builds for the time being.
Reader Comments
Add a Comment
| Name: | (optional) |
| Comment: | |
Comments are the property of their respective owners.
Be the first to post a comment!