Doing It Right From The Start With Continuous Integration

The Signposting project is proving one of the best I've worked on as we've been given the time and the resources to do it right, right from the start of the project. This includes, not least, being able to set up a fully functional (almost) continuous integration environment.

Using CruiseControl.NET, the first step for creating any solution is to add the initial, blank solutions an projects into our build process. In this way, with automated unit testing, potential errors can be caught and corrected early on. Our build process generally consists of three build types for each project:

1. Code Diff: This build runs a tool which does simple metrics on the source code. It runs once a day and we don't care if it is running on successful code or not, so it is run separately to ensure it runs even if the build fails.


2. Daily: Running once a day, this build performs unit tests, further code metrics and analysis and will run integration tests (when we get to that stage).


3. Continuous Integration: Running each time a developer checks code into source code, the CI build compiles the solution and runs unit tests and test coverage analysis.

Using a well configured build environment like this means I, as a developer, have a lot more confidence in my code. The Test Driven Development model we use ensures up to date unit tests that are run locally before each check-in, meaning I am comfortable that bugs are kept to a minimum. It also encourages me to keep code changes small and check-in often. It's great to have the CCTray notification icon in my task bar turn from yellow (building) to green (successful) with the message: "Yet another successful build"... geek that I am.

All in all with sensible timescales, a great set-up, good project management and regular feedback from the 'client' this project has lots of promise!