Click here to Skip to main content
Click here to Skip to main content
Go to top

Secrets for Setting Up Continuous Integration

, 23 Feb 2009
Rate this:
Please Sign up or sign in to vote.
A few simple tips that should help when you are considering setting up CI

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:

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

wallism
Software Developer (Senior) Peer Placements Pty Ltd
Australia Australia
I live in Sydney and have been a developer for almost a decade now. I have a passion for technology and a strong interest in discovering 'better, cleaner, faster' ways to get systems out the door because I believe software development takes too long. If I have an idea I want to realise it as quickly as possible...plus writing systems for someone else I want to deliver quickly so I can move onto the next interesting project!

Comments and Discussions

 
GeneralGood first article PinmemberDonsw21-Mar-09 17:38 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web01 | 2.8.140921.1 | Last Updated 23 Feb 2009
Article Copyright 2008 by wallism
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid