Leaving university, I thought I'd be a developer happily knocking out code but was always drawn to tech support. How do we help people use our tools better? Now, I mostly specialize in consulting and introducing new customers to our tools. I am a Tech Evangelist and Lead Consultant at Urbancode. Eric is a DZone MVB and is not an employee of DZone and has posted 77 posts at DZone. You can read more from them at their website. View Full User Profile

Reducing the Pain of Build Failures

  • submit to reddit

A while back, I sat in on a discussion with the AnthillPro development team regarding preflight builds. A developer working on other functionality had been looking irritated for a while and finally burst out, "I get it. This should lower the rate of build failures. But why do we care? It's not like build failures are particularly common, they are usually easy to fix, and if the build stays failed a while, I can work around it in five minutes. Is there anything there that demands a new feature?"

The answer was no, his development team didn't need new tools to prevent build failures. Other teams though, really do suffer from broken builds. We certainly have customers at both extremes and everywhere in between. What separates teams that can easily shrug off the occasional failed build from the teams that have good cause to fear failed builds?

Researching this question helped us compile a guide that examines why build failures can be expensive and which practices and tools reduce the pain of build failures. The key principles behind pain free building in the guide are:

  1. Keep the rate of failure relatively low and the length of breakages short.
  2. Maintain short builds.
  3. Limit the number of people impacted by a failed build.
  4. Provide impacted team members with effective work-arounds.

Following these principles, we looked at good build practices, release management practices and agile development practices to suggest some practical approaches for improving a team's performance and helping them shrug off the occasional failed build.

The complete guide is available in the resources section of the website here: http://www.anthillpro.com/html/resources/build-pain-relief/default.html.

From: http://www.anthillpro.com/blogs/. (Over the coming weeks, this blog will touch on the various aspects of the guide. We are also interested in collecting suggestions from the community on other practices that help teams perform pain free continuous integration.)

Published at DZone with permission of Eric Minick, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Jeroen Wenting replied on Mon, 2008/12/01 - 3:39am

apart from advertising your services, is there any point in this post?


Eric Minick replied on Mon, 2008/12/01 - 9:51am in response to: Jeroen Wenting

Just linking to the guide we put together. We don't do many services, so we're not advertising consulting. We do have a product, it's barely mentioned in the guide.

The point is:

1) We see some teams really suffering from build failures, and some teams who rarely have build breakages, and don't stress out when there is a failure.

2) We looked at the differences between those kinds of teams.

3) We have some advice if you're in the second group and would like to be in the first group.


All on the website, no registration required, and we're not looking to sell you consulting.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.