Despite having already used many of the tools I’m using to provide the build environment for EmailValidator, it still took longer than expected, so here’s the highlights of the current structure which will no doubt change as the project evolves.
The aim of the build is to provide both a) an easy way for end-users and project developers to build project consistently, and b) provide a means for a continuous integration server to regularly build the project. The continous integration server is key to ensure that when other code is contibuted, it is built and tested and that any failure is fixed as quickly as possible. The aim is to also automate the publishing of builds and testing results to this website.
Continuous integration isn’t a particularly new term, it’s origins area in the daily ‘build and smoke’ test, but is one of the key tenets of eXtreme Programming. The idea of automated tests that fully exercise the codebase is key to the overall vision of a high quality product.
The build process:
1. Clean any previous build’s output
2. Build the project
3. Run automated tests
4. Produce code-coverage reports
For this project, I’m using NAnt 0.85rc3 (built 16/04/2005) to actually perform the build – taking the source code, compiling it, running tests etc. Once the project has been built it’s then time to run the tests, these are done using NAnt’s built-in NUnit task. Finally, code-coverage is provided by Clover.NET.The continuous integration server I’m using is CruiseControl.NET which will currently be running in the background as a service on my development machine.
Clover.NET proved to be the most difficult to wire-in, but this was down to it not being entirely clear which build of CloverNAnt to use, as it happens, it was 0.85.2053. A more recent build (2100) I believe is to fix breaking changes in 0.85rc3+ builds.
Firstly, we load information from CloverNAnt’s assemblies:
This ensures we don’t need to copy the assembly over to NAnt’s directory. The current Subversion repository for the project has both NAnt and NAntContrib under source control – a practice I’ve seen recommended in a few places, including John Robbins’ excellent
so this keeps everything nice and clean and tidy.
Clover.NET works by instrumenting the code before compilation, writing in additional instructions to generate a database of results during execution. So, before compilation, we use the following tasks:
/tests//”/>
<mkdir dir=”${tests.dir}”
unless=”${directory::exists(tests.dir)}” />
Since the clover-setup task **doesn’t automatically create the CloverBuild folder (where it temporarily writes instrumented code to) it’s necessary to create the directory first. The exclusion mask ensures that we don’t instrument (and thefore check coverage) of the test fixtures themselves – just the classes under test. The other thing of note is the final line – CloverNAnt relies on the CloverRuntime assembly to work, and for our tests to run, we’ll need to have the CloverRuntime assembly in the same path. Since all test assemblies are written to the same folder, we just need the one location. Once that’s been done it’s time to execute the tests as normal, and produce the coverage report.
Since this is already long enough (and has taken longer than expected to write) I’ll save the Continuous Integration aspect of the build system for the next post!