Setting up a buildserver...

Several of our projects have grown to the point where the test suite and/or the full suite of builds has become time consuming. Moreover, we’ve been faced more and more with the need and desire to have a set of “official” builds that we use for testing. The current scheme of embedding the version number in the binary doesn’t include enough information to let a tester know where the binary came from. That includes which developer as well as which revision of what branch in the source tree. So I finally got a build server cobbled together (actually two: one for Windows and one for Linux). Myself and one other co-worker did a pretty exhaustive survey of build servers and finally settled on one: Quickbuild. We did so mainly because it seemed the easiest to configure, authenticated against Active Directory, and could support multi-platform builds.

Quickbuild itself is not open source, but there is a lighter version called Luntbuild that is open source. To be fair, Luntbuild has a lot of great features and is pretty close to it’s big brother. However, we really wanted heirarchial builds, which isn’t available in Luntbuild. Moreover, Quickbuild was $2199 bucks for a site licensce. Kind of hard not to make that investment.

I got the build server up and running early last week in just a couple of hours. I tried getting one of our projects to build but was running into a small problem: I apparently needed a step called default. So I created a step called default, and it performed a checkout from our Subversion repository. Quickbuild proceeded to checkout the working copy and call the build finished. At the time, I punted and chose to revisit the issue later. On Wednesday, a fellow co-worker who has been working offsite came to help, and he pointed out the missing ingredient: the default step is usually a serial composition of the other defined steps (doh!). Once I had that nugget of information, we were done in no time flat. By the end of the day, I already had all the builds for several projects running. That includes not only the binaries and installers, but also the unit tests–which clock in at 30+ minutes for one project. I’m hoping to get several more converted over the next week, if all my other responsibilities don’t get in the way. The only thing I felt was missing was a better trigger script for use by Subversion, and real continuous integration support. You can get something very close to continuous integration, but not quite continuous integration. If several commits happen in quick succession, you may actually miss a revision by the time the build server goes out and starts the build process. One other feature I’d like to see is getting the revision number from Subversion into the build string that accurately matches the working copy it’ll use for the build. It would make it easier to identify which revision the build was against, rather than going through the revision log. Other than those minor nits, Quickbuild has been awesome.

The developer response has been great so far. We work closely with our customers, and the new build server will allow us to grab any of the latest builds and pass it off to them easily instead of having to take the time out and do a full build of everything (and to be honest, most of the projects are smallish, so it wasn’t really a problem to do a full build for them… it was only recently that we got a few that demanded more time). Moreover, we can be sure unit tests are run even if a developer forgot to run them locally. Another step accomplished from The Joel Test: 12 Steps to Better Code. Only three left to go.