Over the years I have created and tweaked a set of NAnt scripts to perform complete project builds. The main script takes a single application end point (a web application project for example) and does a complete, from source control, build of it. The scripts are preconfigured with the necessary information regarding build output locations, source control addresses, etc. The main point is that you can feed it very little information and build a given project from the ground up. This satisfies the "arbitrary" part of my question.
In the past I have worked for companies that produce a few software products (mostly web applications). This environment lends itself very well to a typical continuous integration setup where there is an integrator for each product. I have set up integrators to serve as both CI builds as well as integrators to handle a complete release candidate build and QA deployment. These integrators use the master build scripts, so the integrators themselves are very little more than source control monitoring and a call to the master NAnt script.
I now work for a development group that creates many applications. Often, developers are called on to support applications originally built by others. When I started there was no build management in place. I am in a particularly unique position within the group as the lead developer of a 4 person team for one business unit's product suite (around a half dozen complete systems). I have implemented CruiseControl.Net with the master build scripts for doing both CI builds as well as RC builds. This works find for the fixed set of projects within the business' product suite.
I have been using CCNet for many years now so I'm fully aware of what it can do. I have great respect for its contribution to the continuous integration arena as I use it for all the projects in my suite of products. I have stressed to my team the use of the official RC build integrator as the master builder for anything destined for any location other than development. This provides great control over the fixed set of projects that are under CCNet's control.
However, there are other developers building other applications. Some of these are 1 developer projects that are often not even in source control until well into the project life cycle (something else I'm trying to change). Many of these projects are one-offs that won't have much of a life in development after they have been deployed. Despite that, they'll still need to be supported. Integral to supporting those is the fact that without centralized build management of these projects the release candidate builds that go to QA and eventually production are left to be done on individual developer machines. This, of course, provides zero guarantee that everything is in source control among the other factors of a developer machine build.
The issue I've been trying to solve is: what kind of system can I use to provide centralized control over these sort of arbitrary builds? This is definitely not a unique problem. However, in much of the reading I have done about centralized builds, build automation and continuous integration the focus is on fixed projects/products and the task of supporting continued development on them. What types of process are used by business that are doing development on new projects constantly? Are they not using these types of processes?
While the master build scripts do live on the build server, they are clumsy to use. Also I'd prefer to limit the console access to the build server. So some management system is required to provider easier access to firing off arbitrary builds on a central system.
I realize that what I'm looking for may lay under the covers of MS Team Build. Unfortunately, whenever I start reading about it, I get that quicksand feeling when I start getting into the MS marketing material and quickly loose my way, never really finding out if what I want to do can be done with it. Plus, the licensing costs have been addressed as a likely show stopper in some past general discussions on the topic of Team Foundation Server and Team System.
I'm a eager to hear from anyone who has solved this problem who might offer suggestions. I have done some work on a centralized build system based around my master "build-any-project" build scripts. However, what I have is in its infancy and has been constructed to support mainly just the types of projects that I work on. There lacks the kind of support required at this point to handle many application types or the plethora of project/solution configurations that are possible with Visual Studio.