Comments on: Continuous Integration Myth: The Build Must Never Break

By: Nels Olsen

Nels Olsen — Thu, 03 Sep 2009 14:47:12 +0000

What is an acceptable level for broken builds? I am not asking our team for 100% green, but our build failure rate is between 10 and 25%, and 85% of days have broken builds. A good 25% of build failures are “hard failures” (doesn’t compile), but about 75% of those are because the build server is buggy and the failure is not really related to the checked in code. Still, that waste’s other team members time waiting for the build server to report as clean — others don’t care why the build is failing, only that it is and that they will have to hassle with ignoring external failures if they try to continue with their own work.

The time to get a break fixed is on average over an hour. Many on the team think that our build failure frequency, percentage and time-to-fix is acceptable and that waiting 10 minutes at most 4 times a day to run a smoke test suite before checking in is a “nightmare”. They argue that the time is utterly wasted waiting, since we don’t do things like review requirements with the customer / product owner, do TDD, pair programming, etc. which allow you to start some work on the next task.

By: a little madness » Continuous Integration Myth: Large Teams Only

a little madness » Continuous Integration Myth: Large Teams Only — Mon, 05 Jan 2009 21:41:48 +0000

[...] been a little while, but my theme hasn’t finished yet. In this case I am revisiting an idea I posted about some [...]

By: Jason

Jason — Mon, 24 Nov 2008 22:40:24 +0000

Hi Chris, narup, Eric,

Thanks for the positive comments.

@Eric: Yep, personal/preflight builds are a brilliant tool, but no magical solution. They suit some projects and situations better than others.

By: EricMinick

EricMinick — Sun, 23 Nov 2008 14:59:40 +0000

Well put! Over in the urbancode office, we use the same language about pessimistic and optimistic locking. Happy to see that you guys do as well. Occasional build breakages should be ok, and if they are a major productivity killer for some team, that’s a bad smell the team needs to address.

I’m also glad to see some someone else discussing personal builds (we call them preflight) in a sane way rather than as the solution to “unbreakable builds” which would require stupid levels of serialization.

By: narup

narup — Sat, 22 Nov 2008 22:25:37 +0000

ya i agree.. i am working in a project where breaking build is one of the biggest crime, so no one wants to refactor the code even if it’s getting ugly and worse.

By: Chris Read

Chris Read — Thu, 20 Nov 2008 17:02:16 +0000

I totally agree on this one, and I spend loads of time telling clients about this. CI is all about feedback, and acting on that feedback. Broken builds are information, use it as such…

Chris