I've been building using nAnt for about two years now.  each project in our enterprise has a nant build file.  This file expects all dependencies to be available either in the root or the bin directory, whichever is appropriate.

I built a custom build utility application that manages inter-project dependencies and the build process.  It has served us well.  At least I think it has.

I want to move in the direction of more iterative development and integration.  Today, I took a first step.  I set up Cruise Control to operate on our enterprise projects in VSS. 

First I had to create a build file that would set up the entire suite from visual source safe.  This isn't that hard to do when dealing with the latest files.  So I created one target for each project, specifying where to get the source files from. 

Then I worked from the most stable project (with the least dependencies and the most consumers) to the project with the most dependencies, setting up the call to the build file in each source directory and then the copy of the next project's dependencies into its source directory (or bin, where appropriate).

It was enlightening to go through this exercise!  I found that each project, almost without exception, built on top of its child projects dependencies.  Example: (in this case, project refers to source and assembly refers to compiled result)  Project B depends on Project A.  Project C depends on project B and A.  However, project B contains the result of Project A, as it is required for project B's assembly to operate.  Some people may not want to keep a copy of Assembly A with Project B's build result but I think it makes sense.  That way, you can use Assembly (or project) B without worrying much about Project A as long as you get Assembly A when you get the artifacts of Project B.   Therefore, you do not need to explicitly manage Project C's dependency to Project A if you get the related assemblies for Project B.  When its time to set up the dependencies for Project C, just get the compilation result of Project B.

There were a few 3rd party dependencies that needed to be explicitly retrieved from VSS but the final build file was manageable and logical.

Once the build file was set up, I moved on to Cruise Control integration.  I had set it up previously with a small test project.  This helped a lot.  It took the complexity described above out of the equation.  I had only defined one project, previously.  I replaced the test VSS path with the real one and was in business, almost.  First, the change monitor in the sourcecontrol plugin gets the files to a local directory.  I am curious as to whether I can use the same directory for the monitor and the build.  I think its likely that the above mentioned dependency management may corrupt the modification monitor process.  I'll experiment with that and report back.  Second, I have all these inter dependent projects as part of an enterprise solution.  I don't want to monitor and build them independently, I want to integrate them!  Continuously.  That's the point, right?!  The latest version may handle this better, the version I used is out of date. 

So that is the experience so far.  I plan to put together a step by step for those who dare to venture down this road.

Bottom line?  if changes are integrated sooner, problems are caught earlier and resolved immediately.  Developers have, fresh in their mind, the changes that need to be assessed.  If tests can be introduced a little at a time, the application can slowly become more stable and dependable.  If development can be reviewed in a stable development deployment without developer interruption, sponsors and managers can have provide better feedback and more contribution to the overall development effort.  Its a communication tool.  It communicates how things are going.  I like that, it makes me feel comfy.