Getting Started with Continuous Integration

The term ‘Continuous Integration’ is thrown around a lot at the moment. It’s one of a series of buzzwords used by “the agile community”. These members paint a picture, a beautiful dream of perfect software development, of war rooms with plenty of space, whiteboards everywhere and separation from the noise, smells and politics of the rest of the company. In these dream worlds, bugs are a dirty word, and enhancements are delivered on index cards. Once coded, these changes are known to be perfect thanks to a army of unit tests, carefully designed (at great expense) to validate every function of the system. “Deployment”, such as it is, tends to happen overnight, unattended and always works perfectly.

You may think I’m an un-believer – that this can’t happen. Well, I’m not. I know this could happen. I’m fairly certain that is should be happening everywhere. It’s just I’ve never seen it actually happening in its entirety. I’ve read case studies of groups that have achieved this nirvana of software development, but I’ve never been able to recreate it.

I’ve tried twice already to create this dream in places where I’ve worked, and it hasn’t worked. This time, third time lucky, I’m documenting the process. I’ve only just thought about documenting it, so we’re already a bit behind. That doesn’t matter too much though, because I’m lazy, so we haven’t got too far. The other reason for documenting the process is that, having done at least some parts of the process 3 times now, I’ve picked up idiosyncrasies which may be useful to someone.

As a gentle primer, lets look at what Continuous Integration actually means. Well, as I see it, it’s another way of describing your set up of auto-builds. An auto-build is just that: it’s a way of being able to build your project/website/solution totally hands-off. In a single mouse click your solution should be able to get all the code from your source control repository, place it somewhere clean, build it, test it, and then publish it somewhere where you can use it. If you can do all that without having to get involved, then you’re auto-building.

The reason it’s called Continuous Integration (CI) is due to a small change you make to the process. You tell your auto-build process to keep an eye on your source code and, whenever it changes, kick off the building process. This means that, if you’re having a good day, your auto-build process may re-build your source code tens of time, each time incorporating a small change. Because of this, you’ll know instantly if something you’ve changed in Assembly A has had an unintentional effect of Assembly B – which you probably never would have thought about until it happened.

CI isn’t just for large teams of geographically spread developers working on different parts of a integrated solution (though it’s very handy for these people too). Even a lone developer, working by themselves on anything larger than a pet project, will benefit from CI. Why? Well, I think it’s because it instill confidence in what you’re doing. Knowing you’ve always got a fully built product ready to go can be very comforting, especially towards the end of a project. If you’ve introduced unit-tests that are run in each cycle, then it’s great to know that all the tests are still passing.

Having the latest build always available can also be helpful to other people in the business: project stakeholders. They’ll appreciate always being able to get their hands on the latest build, and you’ll appreciate them not hassling you for new builds all the time. Obviously, you’ll need to manage expectations early on in the process as your initial builds won’t be anything near a finished product. Some people can take a while to get used to this idea of complete open-ness, but I think it definitely works out better in the long term.

Over the next few weeks I’ll go into technical detail about setting the whole thing up. In my setup, I’ve used nANT, and CruiseControl.net to manage the build process. The actual build work is done by MsBuild with unit-testing performed by FxCop. Unit Tests are written with nUnit. There will be separate posts on all of these soon. I’ll compile a list of the blog entries here as well.