Reducing the Pain of Build Failures
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:
- Keep the rate of failure relatively low and the length of breakages short.
- Maintain short builds.
- Limit the number of people impacted by a failed build.
- 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.)
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)