Build servers are for more than just building

Using a build server (such as CruiseControl doesn’t mean developers shouldn’t run local builds (even though broken builds aren’t really as serious as a lot of people make them out to be). So this raises the question: if developers run their build locally, what’s the build server for?

Here’s a list of the things I use a build server for, taken from a message I sent to the XP mailing list a while back.

I always advocate that developers build locally first. My version of “local build” is a full release cycle: compile, package, deploy, test. I aim to keep this really fast; when it gets past a minute I get edgy (I strive to keep unit tests inside of the IDE to under 10 seconds). Integration-level tests are another step on top, and developers are encouraged to run that as part of, well, integration, as well as most acceptance tests. The end result of this is a system that should be releasable. I would be surprised if there were really significant differences between what I advocate to my team and what you advocate.

What I use asynchronous integration for is:

  • as a safety net, in the event that developers are not running their local builds. Build failures which should have been picked up by a local build are serious; a pattern of them means that it’s time to refocus on that practice.
  • an information radiator of the current build status. I find that not knowing if the build is good or not gives me concerns. 🙂 Sure, I can ask, or I can even assume it’s good, but knowing is better.
  • producing real release builds; this is just a side effect of the fact that it’s the controlled reproducible environment; it’s also a sop to the QA teams (who previously insisted on doing release builds themselves… *shudder*).
  • a monitor of important, but non-urgent, information. Looking at my current build system, this includes code coverage, dependency analysis, coding style enforcement (also run locally), duplication detection, documentation generation, and statistical information. This stuff gets reviewed periodically, and is not worth examining all the time; however, various threshold levels produce warnings.
  • a repository of historical information. I can easily see how often a team releases code back to the repository based on how many builds they do – I’ve had teams that produce upwards of 10 release builds a day; I’ve also been on teams that struggle to do that in a month. 🙂 I can also see historical information for some of the “important, but non-urgent, information” (particularly the code coverage).
  • a “warning bell” for shared components, allowing me to easily see if a new release of a component breaks any of the dozen or more projects that use it.
  • running longer running tests. In many cases (e.g. performance profiling), these are not of a pass-fail nature, but more to do with keeping an eye on the trends (again with threshold warnings). Some are just long running because they are long running; imagine an acceptance test that invokes a report that takes 30 minutes to prepare with production data, or a workflow process with a forced 2 hour delay.

All of this is information I find valuable, and thus important to me. None of it is really worth asking developers to run all the time (though I do often get people to focus on small parts of it for an iteration).

Advertisements

Author: Robert Watkins

My name is Robert Watkins. I am a software developer and have been for over 18 years now. I currently work for people, but my opinions here are in no way endorsed by them (which is cool; their opinions aren’t endorsed by me either). My main professional interests are in Java development, using Agile methods, with a historical focus on building web based applications. I’m also a Mac-fan and love my iPhone, which I’m currently learning how to code for. I live and work in Brisbane, Australia, but I grew up in the Northern Territory, and still find Brisbane too cold (after 16 years here). I’m married, with two children and one cat. My politics are socialist in tendency, my religious affiliation is atheist (aka “none of the above”), my attitude is condescending and my moral standing is lying down.

3 thoughts on “Build servers are for more than just building”

  1. I like Mike Clarke’s post “Dear Manager, They Need A Build Machine”. He says “If the build succeeds on the dedicated build machine, it means that anyone on the project can create a build given access to your version control system” – you have one machine that builds only based on whats in version control so you know if any necessary files have not been added / checked in (“it builds on my machine!”).

    http://www.clarkware.com/cgi/blosxom/2004/10/19#TheyNeedABuildMachine

  2. Ah, but I had nearly finished my device that provided 5kV shocks to developers once the build broke (with escalating frequency of bolts).

    So now, maybe I shouldn’t you say ?

    Seriously though, it is amazing what silly things can go wrong when you take production releases from different machines, so that makes a build server pay for itself, I reckon.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s