I encourage every one (even single developers) to use a Sourcecontrol system such as SVN and AnkhSVN to do development. Put all your project files (and external dependencies) under source control and maybe even get a continuous integration server setup.

And still, even if you’ve done all of this, chances are high you still have one external dependency in your project: the Database!

And this is where the pain starts, if you don’t find some way how to put your DB schema under source control too, you’ll end up going back to old versions and having no database of that date.

There are however several ways to solve this that I can think of:

• Make your CI server fetch a schema script every time a build is triggered.
• Make creating a schema script part of your build process

And .. guess what? There’s a simpler way :).
If you’re using a ORM tool you should always have your database model somewhere in the mapping files.

Because the mapping files tell the ORM the structure of the DB, they essentially contain all relevant information needed to generate a schema without the need to have SQL scripts.

In NHibernate for example, you can simply do a:

var cfg = new Configuration();
cfg.Configure();
cfg.AddAssembly(typeof (Person).Assembly);

new SchemaExport(cfg).Execute(false, true, false, false);

And the mapper will go out and create all necessary tables and relationships in your database.

By having an ORM capable of recreating the schema, I no longer need to keep the Database itself under source control, because the necessary information to recreate the schema is already in my source tree.

After playing around with Log4Net and the Castle MicroKernel, I suddenly discovered that not having those external dependencies under source control makes development quite difficult.

Whenever I update my dependencies, all other people on the team need to adjust theirs to match mine and vice versa. This is a minor annoyance while the team is small, once you grow and have people coming in and out of the team you’ll start to feel real pain!

If sucks even more if you’ve already shipped your application and get called a year later to change something. Trust me, digging up the right version of library X isn’t getting easier over time, and updating the application to a new version may either break the application or cause your customers to update too (both highly undesired!).

So, what’s the right solution to dependencies?
(No it’s not reinventing the wheel over and over again by writing everything by yourself)

Simple: Put the dependencies into a folder called /lib/ and reference them from there, set the “Copy To Output Directory” option to “Copy if newer”.
Then add this folder to your source control and you’re set. Whenever a new guy comes to the team and gets the project from source control, he’s guaranteed to be able to build it without having to run around some random site searching for referenced assemblies.

Ok, since my last post where I tried out CruiseControl.NET some time has passed.

Although I said last time setting up CCNet is easy and quick, this time I didn't listen to my own advice, and so when I needed a Continuous Integration system I went TeamCity.

TeamCity is great, just click on some buttons and your CI is running.
Log in to the website, configure everything through GUI and you're done.

Sadly, I wasn't done. Something with TeamCity's build runners wasn't working right and it wouldn't resolve my NUnit dependencies and fail to build at all.
I then tried to troubleshoot TeamCity for almost a day before I finally gave up and just installed CruiseControl.NET again.

CCnet on the other hand just worked great, and I was up and running smoothly after an hour or so. And since my last post was lacking, after the break is a step-by-step guide to setting  it up.

Subversion

I assume you have Visual SVN Server up and running already (or something else), so I'll skip this step.

CruiseControl.NET

Download and install the latest CruiseControl.NET from SourceForce

During installation CCnet installs two components, the webdashboard and the CCnet server. The webdashboard will automagically be installed into a IIS virtual directory so you can access it through http://localhost/ccnet

Although you can already access the webdashboard, you will not find much to do there since the CCnet service isn't started by default and is also lacking configuration.

Configuring the CruiseControl.NET server

Now, this is when the fabulous CCnet documentation comes in to play.
In the C:\Program Files\CruiseControl.NET\server\ directory you'll find a file called ccnet.config
I won't cover all basic steps since they are already well documented, but just point out the important ones in my config.

<sourcecontrol type="svn">
  <executable>C:\Programme\VisualSVN Server\bin\svn.exe</executable>
  <trunkUrl>https://localhost:8443/svn/myProject/trunk/</trunkUrl>
  <tagBaseUrl>https://localhost:8443/svn/myProject/tags/ccnet-builds/</tagBaseUrl>
  <username>username</username>
  <password>password</password>
  <autoGetSource>true</autoGetSource>
  <tagOnSuccess>true</tagOnSuccess>
</sourcecontrol>

The <sourcecontrol> block configures CCnet to access Subversion and retrieve the source. Notably: tagOnSuccess will automatically create a new tag in the tagBaseUrl directory depending on the later labeller block.

<labeller type="defaultlabeller">
  <prefix>myProject-alpha-0.1-build-</prefix>
  <incrementOnFailure>false</incrementOnFailure>
</labeller>

This labeller block has many many options for labeling your build, but I choose to just increment my build number on every successful build with the defaultlabeller. It's a bit too early for my current project, but at a later stage I think I'll exchange that labeller with a iterationlabeller that calculates an iteration number based on weeks since release in addition to the build number.

The nunit block in the tasks section defines where my NUnit console runner is located and what assembly should be tested upon build. It's pretty straight forward, but still I think it's important.

Yeah, and that's all. XML Configurationa always looks awfully complicated, but once you look over the angle bracket porn you'll find it pretty easy to configure and modify.

One tip though: Never try to debug your configuration through the windows service. Run the ccnet.exe from the console so you get all debug output to the console. This makes fixing and tweaking your ccnet.config very easy and less "voodoo".

Because starting is easiest with a sample configuration file. Here is mine:

ccnet.config