First, please go to:

http://workspaces.gotdotnet.com/busybeebuilder 

There, you can download my favorite pet project the BusyBeeBuilder.  The MSI installs the binaries, source, and docs.  It's a clean install--and it uninstalls cleanly too. 

I'm a HUGE fan of automated builds and testing.  I get great confidence knowing that an application is being built two, three, heck 10-20 times a day:  AND, that all my NUnit's are being run that often.  I've exposed many races, deadlocks, bad network-code error handling, incorrect crypto keys, missing user accounts, missing databases, changing environment, etc. etc. in these automated tests.  By the end of a three-six month project, your tests have run hundreds of times. 

I wrote BBB to use on consulting gigs.  I'm always surprised how few people are practicing continuous integration or daily automated builds.  Primarily, few people do these because they're just to damn hard to set up and maintain. 

Where does BBB sit against other automated build solutions? 

1. BuildIt:  BBB allows more extension, and offers more flexibility
2. NAnt:  BBB is quite a bit simpler to set up
3. Whidbey's MSBuild:  BBB is available today, MSBuild ships with Whidbey

What does it DO?

1. label and pull from SourceSafe
2. copy/move/delete files and directories
3. build from the .SLN (solution) file; it doesn't require you to manually resolve dependencies and set up awful MAKE files, on the other had it depends on Studio's command-line build
4. Runs NUnit tests
5. Runs FxCop
6. Archive the build
7. Email the results of build, tests, and FxCop to the team

How does it WORK?

It's a basic pipeline.  BusyBee itself, in the BusyBeeBuilder.Library namespace, is just a framework for running "build workers".  The core itself has minimal knowledge of the build process.  It just walks through the config file looking for BuildAction nodes, instantiates the BuildActionWorker specified by the node, feeds it the Parameters name-value collection in the node, and calls it (Command-pattern style) through its Execute method.  The core has been through quite a bit of rough handling.  It's quite good about yanking the rug out of under ill-behaving build steps; every build step gets a specified number of minutes to complete, and BusyBee cleans it up if it goes too long.  The core has been written very defensively to protect itself against build failures and stand up over time--it's running as a Service, and it MUST perform the builds on time!

The config file gets re-hydrated into a bunch of config objects, which are the data that drive the framework.  The config objects use the Configuration Management Application Block, so they're able to save/load themselves from the config file.  This is important, because it means you could just create config objects, set their properties, add to their collections, and feed the whole thing back into the config file--hint, hint, it's an admin GUI dream...

The config file can specify one or more BuildTarget nodes; each one is an application to be built, so you can have your build server building multiple independent applications for your team. 

The BuildActionWorkers are just implementations of the IBuildActionWorker interface; they're instantiated dynamically as plug-ins from a Factory, so they can be developed independently and dropped into the BIN directory when you want to extend BusyBee. 

BBB natively runs as a Windows Service.  It doesn't have much of a UI.  At present, I have a very thin remoting-driven GUI that allows developers to point at a build server, tell it which application to build, and kick off a build manually.  BUT, the GUI does show how one could extend BBB...

Is it Reliable, Is it Being Used?

Yes and Yes.  It's been used at several companies for a year now and it's gone through several revisions, with the latest Service-based version 2.0 having been in use for about eight months.

How should BBB Improve?

BBB needs a GUI for build setup and admin.  Right now, you basically look at the app.config that ships as part of the Console or Service projects; those are the build files I use during development to test it.  They're also good examples of how a production build config looks. 

So you pattern-match those, and hack together your own config files.  What I'd REALLY like is a nice GUI to do it, and it would be pretty easy to do.

Here's how I'd approach it:

• the config objects are just OO representations of the stuff in the config file
• the Library (BBB framework) uses the config objects as its data source; it's isolated from the config itself
• the config objects can use the ConfigHandler to .Read and .Save themselves to config xml via the CMAB
• So:  to make a GUI, just create a wizard that sets up the basic BuildTarget, then adds BuildActions to it one at a time.
• A sophisticated GUI would allow you to reflect over assemblies looking for IBuildActionWorker implementations
• Said GUI might also include validation steps--for instance, looking to be sure files exist, directory paths are OK, or even doing dry-runs of putative BuildActions to test them.