Posts Tagged ‘ Agile ’

Getting Started With Continuous Integration

In Less than Ten Minutes!

This article is all about how you can easily get up and running with CI in less than 10 minutes!

There are really two separate parts to gettings started with CI (and therefore two parts to this article).

  1. Setting up the build server and
  2. Creating the build (e.g. Nant files)

Then there are the issues you will face and need to find some form of resolution for.

First you need to download and install these tools:-

  1. Cruise Control
  2. CCTray (same location as CruiseControl)
  3. NAnt
  4. NAntGenie

And Add the path to these exe files in your Environmental Variables

  1. NAnt
  2. msbuild (something like ‘C:\Windows\Microsoft.NET\Framework\v3.5’)
add path to NAnt and msbuild

add path to NAnt and msbuild

Presumed Knowledge

These are demo notes from a ‘lightning talk’ I gave at the Sydney Alt.Net user group in February.

In the talk I had only 10 minutes, so I made the presumption that all in attendance knew what CI was, if you don’t then check out these links, they will get you started:-

Martin Fowler

Extreme Programming Rules

The Build Server

I’ve always used Cruise Control as it has always met my needs, is free, simple to get up and runnning and pretty much trouble free. For the demo I used version 1.4.2, when you download it, make sure you also get CCTray.

There are a number of other build servers out there that are definately worth looking at and comparing, I’m especially keen to try out Jetbrain TeamCity…when I find some time. It doesn’t matter which one you choose.

Setup CCTray

  1. Install Cruise Control (keep all of the default settings)
  2. Install CCTray (start it)
  3. Ok so now open CCTray settings and add (try to) a new build server.


Connect directly using .Net Remoting is the default, change it to Via the CruiseControl.NET dashboard (just a recommendation).

Click OK and you should see at the bottom a message saying, ‘Failed to connnect to server….’. We going to fix that right now.

Configure The Server

First thing we need to do is configure the service.

  1. Go here [C:\Program Files\CruiseControl.NET\server] or wherever you chose to install it.
  2. Open ccnet.config
  3. This is where things get personal. The example below is a basic configuration to point to an SVN Repository. The documentation on the Cruise Control website is concise and easy to follow so if your needs are different you’ll have no problems figuring out what you need to do.
  4. Add a ‘Project’ with the follow config sections:
    1. Trigger
    2. Source Control
    3. Labeller
    4. Build Task
    5. Publishers
  5. Save and double click on ccnet.exe
  6. You now have a working automated build! (well sort of…we still need to do the second part of the process, THE BUILD!)

TIP: Don’t forget to change the verbosity of the output to INFO (it’s currently DEBUG). Don’t worry CC will remind you every time it starts and tell you where the config file is that you need to change.

This is the contents of the config used in the demo, change it to suit your environment and save. Make sure:-

  • The path to NAnt.exe is correct.
  • The trunkURL for your repository is correct (or replace with appropriate section for your repository)
  • Working directory and publish from directories are the same.
  • You may need to make sure the SuccessfulBuilds directory exists before running…

Create the Build Files

The other big piece of the puzzle is the file and the associated files.

My tool of choice here is NAnt and I use (wrote) this generator to automatically create my build files and the

To create these use NantGenie (be sure to read the Notes section)…or you can write them from scratch.


That’s it you should be good to go. Start ccnet, checkin a change to your source, the build should start and run your new file!

White Lie

Ok so here’s where I have to come clean. It may have been a little white lie when I said that you could get CI up and running in less than 10 minutes. You are going to run into some other issues that is going to make it take….longer.

I discuss some of these issues in this article. But in a nutshell these will be the biggest thorns in your side:-

1. Database changes

Ideally when you check your code in, you are checking in a ‘unit of work’. This could include some app code changes AND some database changes, e.g. a new column and some data. Your tests rely on the database being up to date, so how do you ensure that the database on the build server DOES get updated when you checkin?

I’ve created an automated Db updater and put it on codeplex, it works for me. Check it out and I recommend looking at what other alternatives might work in your unique environment.

2. App.Config changes

So what is the best way to ‘manage’ the app.config files?

I don’t have a definitive answer for this one but I think that the following conditions are ‘desirable’ when planning how to manage your app.config.

  1. Like other code, you don’t want to have duplicates (including cross project).
  2. You only want data in there that is relevant to the project.
  3. Must be under source control.
  4. You want to be able to define what the variable contents should be in one place only. (where doesn’t matter too much as long as it is only one place)
  5. When you make changes to your App.Config, you want to make them whilst you are working on your relevant code change and then forget about it once it has been checked in. By ‘forget about it’ I mean you don’t have to remember to update the file on the UAT box when promoting a new build there and then remember to do the same change to Production…

All of this is tricky with an automated build and multiple environments.

3. People

Probably your biggest hurdle will be convincing people that CI helps and that they need to CHANGE their habits a little (sometimes alot) in order to make it work.


  • If you’re struggling to figure out why the damn build is broken, the best place to look is here [C:\Program Files\CruiseControl.NET\server\YourProject\Artifacts\log].
  • Also, don’t forget you can also turn the verbosity of the CC server back to DEBUG.


Hopefully this article will help reduce the time it takes to get some CI action happening in your team. Yes it is going to take more than 10 minutes but I guarantee you it is worth the effort and once you start using an automated build you simply refuse to go back to the chaos that preceded it!

Secrets for Setting up Continuous Integration

I’ve set up CI in my last two roles and have spent a little bit of time trying to simplify the process whilst doing it and thought I’d share a few ‘secrets of sucess’ for getting CI up and running.

So what makes CI easier?


I wrote my own code generator that searches through my entire dev directory for project files (I work with .Net so it simply looks for .csproj files) and generates a NAnt build file for each project file. I also generate the file. If there isn’t already an existing CodeSmith template for this type of thing then it’s not too hard to create your own generator (code generator = fancy string builder). This is what I’ve done.

Generating your build files is also important because you then know that all of your projects are built in a consistent manner. Plus when you make the build files cleverer you can easily apply those changes across all of your build files at the push of a button (ok a few buttons maybe).


This is a whole other topic in itself but I’ll try to keep it brief (of course ignore this one if your app does not hit a database). The biggest challenge you will face is handling database updates effectively. Your build box, test box and of course production box all have their own database and ideally each developer runs their own local copy (unless size does not permit). The problem is, when a developer checks in his unit of work which includes a database change (new table and some data for example), when the build kicks off how do you ensure that those database changes are run against the build boxes database?

You must have an automated program that runs any new scripts and this program must be one of the first things run as part of your build process. So what if one of the scripts fails? Ideally your program will run all scripts in a transaction and simply rollback the transaction if any of the scripts fail. This will work on SQL Server but sadly on Oracle any DML script will cause a commit of the transaction so you must find another (like backup first and restore on failure).

Developers use the same program to update their local database and the program is also used when promoting to other environments. By the time you run it against production you will potentially have hundreds of scripts (which I have experiences) so make sure you have a good naming convention (or other technique) that ensures the scripts get run in the correct order.

All changes to the database must be made with a script, no exceptions. (not exactly a new rule but it amazes me how many people do not follow it!)

I wrote my own program to handle this and I’d be very interested to hear what others have done.


From developers to the CIO. The CIO needs to understand the benefits that this new process will provide because it is going to take time (and money) to get it setup (money and time that will DEFINATELY be recouped over time).

CI forces a more disciplined approach to software development, some developers will not like that so it’s important that they understand the benefits that they will see with the new process (like knowing that doing a get latest will always return a working copy of the source!). Developers will get annoyed with the new process if they don’t understand it properly and keep breaking the build.


We are still working with a crappy old desktop. It takes longer to build and we continually have clean it up as it fills up pretty quickly. Frustrating!


#1 – If you break the build it becomes your highest priority to fix it.
#2 – If the build is broken no further checkins are allowed until it is fixed. (except of course by the guy fixing)
#3 – No chicken runs…means no checking in just before you go home. (this rule is the only one that is flexible)


If you delete everything in your development directory on you build box (i.e. where all of the source code is) and then start the build it….it should work! If it doesn’t then there is a dependency in there somewhere that is not in source control.

Every developer I have spoken to who has used CI tells me there is no way they could work in an environment that does not use it, so it may present some challenges setting it up but it is well worth it!

Update…Check out this article too!