Secrets for Setting Up Continuous Integration

• Download source code - 1.02 MB
• Download latest version of source code from CodePlex

Introduction

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 success' for getting CI up and running.

What Makes Setting Up CI Easier

1. Generate Your Build Files

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 master.build 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). I'm also happy to share the generator if anyone is interested (will put up on CodePlex).

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).

It's taken a while, but I've finally made my source available on CodePlex.

2. Automate and Control Your Database Update Process

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 his/her own local copy (unless size does not permit). The problem is, when a developer checks in his/her 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. I've been meaning to put the source (C#) up on CodePlex for ages, let me know if you are interested and I'll let you know when it goes up.

See the link below for the Automated Database Updater on CodePlex!

3. Get 'Buy In' Before Starting

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 DEFINITELY 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.

4. Get A Decent Build Box

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

5. Make Rules From Day 1

• #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.)

6. Clean Build

If you delete everything in your development directory on your 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.

Summary

Every developer I have spoken to who has used CI tells me there is no way she/he 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!

If you are not doing CI....what are you waiting for!

Points Of Interest

I should also mention that this is one of the few articles I'm working on relating to build processes and 'simplifying the boring stuff' so you can focus on what you really enjoy...writing cool code! Other articles:

• An automated database update program on CodePlex
• My new blog on Getting Started With CI in Less Than 10 Minutes!