Building blocks Apr 10 2006

So before I get cracking with a few ideas I’ve got going on, I wanted to get my base framework and build environment sorted. After taking xFramework offline and turning all of the useful code I wrote into a more condensed, useful set of libraries, I then decided to work on a few build tools.

First up was to refine the unit-testing libs and console tool that was part of xFramework. Re-named, and re-built, I made it leaner and faster. Previously, there was one core library - this was the same one the console tool used to execute tests, and the client library containing the unit-tests referenced to tag unit-test classes. Now, it’s two separate libraries - a client framework lib referenced to mark up unit-test classes with attributes, and a console tool with core library (and a reference to the framework lib) to execute unit-tests themselves.

Secondly, I wanted a build server. I searched a while back, and came up short. There are plenty out there, but the criteria I’m after is:

  • Automated build setup, with an easy-to-use configuration structure
  • Plugin interface for a totally extensible build and reporting process
  • Cross-platform, runs on both Linux and Windows, and preferably Mac OS X too
This is the basics of what I wanted, but it’s a start. Anyway, I decided a while back I’d write my own, and got a way through it before more important stuff took precedence. This time, I decided to stick at and get it done. I started from scratch, only referring to the code I wrote previously for a couple of things, more as a source of comparison. I now have a fully extensible build system, which so far has the ability to:
  • Checkout a working copy from a Subversion repository, either using the “file” or the “svn+ssh” protocol. I’ll write further SCM support as and when I need it.
  • Build the project, so far the only supported plugin is an MSBuild plugin, for building MSBuild project files such as Visual Studio 2005 solutions and projects (of course the API should be fairly similar to the XBuild tool for Mono, which was a port of MSBuild, and I’m thinking about a NAnt provider somewhere down the line)
  • Run some code metrics, so far just a simple line counter for each file meeting the configured criteria, and a total line count
  • Run unit-tests on the code, using my unit-testing framework, and a bridging plugin for the build system
  • Generate some documentation, using my own documentation engine (see below)
  • Cleanup after itself
All of this can be done using a series of plugin schedulers, also extendable to provide further scheduling options, however currently providing hourly and daily schedulers, aswell as a run once scheduler (runs immediately, once only) and a continuous build (building over and over) for testing. Eventually I plan to write a scheduler that queries the source code system for updates, thereby turning it into a continuous integration build system too.

Now that this is done, and tested, there are a few other plugins I want to write for it, but on the whole it’s good enough for me to develop with now. The build reports are also extendable - an interface is defined so that plugins can be written to deal with the build report, and so far I’ve written one provider that saves this report to file, and one that mails it to me, both of which I use. This means I now have my project building nightly, with everything automated, and me being notified of the results.

The third and final tool I’ve written, is a documentation engine. This came about purely because I tried writing an NDoc documentation plugin for my build system, to no avail (it didn’t like my .Net 2.0 assemblies). I browsed around, and found two things: 1) there is little or no activity currently occurring on the NDoc project, and 2) a few users are starting to modify the source themselves to provide a source distribution of NDoc with support for .Net 2.0. I took one look at the Xml documentation files that the C# compiler outputs (the ones that NDoc uses) and decided instead of using unsupportable, possibly unreliable user hacks to get my documentation needs accomplished, I’d write my own little engine, and in this way I’d get exactly what I needed. And so my third development tool in my toolchain, a core library defining a plugin interface for document generation, was born. It allows project files to be configured (defining the Xml document input files to use), and it allows plugin documentation generators that handle the actual output - I wrote one simple plugin to provide Html output for now, more advanced output could be Linux style man files, a Windows style help system, MSDN docs, or a multi-page Html documentation web site solution (currently it chews out one Html file, using JavaScript to allow expanding/collapsing of elements). I have written a console tool to build documentation from the project file, and of course the build server plugin is used to generate documentation directly from within the automated build process.

I now have an end-to-end build process, which, while some tweaking and a bit more code writing is necessary, does the job more than adequately for me. I feel far more confident going on to build upon a lot of my ideas, knowing I have the building blocks in place to write and develop applications more reliably.


Technorati Tags: , , , , , , , , , , ,

coding • dotnet • el • eldiablo • mono • pc • personal • programming • tech