Recently I have installed CruiseControl.NET – a continuous integration server. It was a good move. My previous encounter with continuous integration involved just a set batch scripts. Although I could do just fine with batch scripts, I feel much better now when I have a proper build server setup. My build server consists of the following components:
- CruiseControl.NET – continuous integration server.
- Subversion – version control system.
- MSBuild – my build tool of choice.
- NUnit – unit testing framework.
CruiseControl.NET
CruiseControl.NET is and continuous integration server and it’s an integral part of your build server. Basically, it listens to your source control system for changes, and if there was a change, it builds your project(s).
It takes some time to configure your projects, but once you have it up and running, you’ll enjoy:
- E-mail notifications for successful and failed builds.
- Automatic unit testing
- Other automatic tasks such as checking your code with FxCop, NCover, etc.
- Web interface for monitoring project health.
Couple of minor things that I found lacking in CruiseControl.NET, though:
- One is a lack of Forms authentication and per-project access control.
- Another thing is a lack of manual tagging of builds. E.g. at some point of time, having a successful build, I want to create a tag of the current revision in my source control for this project with single button click.
Other than that, CruiseControl.NET is a must if you have a .NET project and there’s more than one person working on it. Even with a single developer projects, continuous integration is useful so that the client can check/test the project at any stage of the development.
Subversion
I love Subversion! It’s a great version control system. It’s based on an older CSV system. Won’t say more – there’s plenty of info about it around.
I have tried a couple of Visual Studio add-ons, but wasn’t happy with that, as those created more problems than solved. I’m determined to find a good SVN add-on for VS one day.
MSBuild
That’s what I use to build my .NET project. The fact is that if you are using Visual Studio, you are using MSBuild, as that’s what VS is using in the background to build projects.
MSBuild is distributed as part of the Framework.NET package.
The Project and Solution file formats use by Visual Studio are supported by MSBuild. This means that your solution/project file is your build script. If you have some linked files between your projects – MSBuild will find them. If you have some pre- or post-build actions specified- they will be executed by MSBuild.
NUnit
NUnit is the core of test-driven development in .NET and a must have for unit testing in .NET. How do you know that the change you’ve just made to that method won’t break the rest of the project? Ok, it builds, it run and seems to be ok. But you’ll never know for sure until you check everything. Every time you make a change and are ready to commit those changes to SVN.
So, NUnit lets you define those tests and run them manually before you commit, of automatically of the build server. If for some reason one of the tests failed, the whole build will fail and those involved will be alerted.
This briefly outlines a basic build server setup and its core components. It can be as complex and as feature-rich as you like, but the basics stay the same – your build server automates repetitive work and ensures that it’s done right.