views:

148

answers:

5

We have an automated build server that builds our code nightly, which is useful for us since not everyone on our team can build the entire source tree. Lately, some members of the team are becoming more lax about fixing build errors promptly; sometimes weeks will go by without a successful build. I even overheard one developer say, "the build is already broken, now is a good time to add [some breaking change]." Since I work on the the code the furthest downstream, I am usually working with parts of the tree that are woefully out of sync with the source code repository, which makes it very difficult to test changes before I submit them.

I feel like we're losing most of the benefit of having a nightly build since it is continually broken. Am I way off base here, or should fixing the build be a higher priority?

+4  A: 

Those devs clearly need to be kicked back into shape.

I'd suggest building at least a few times daily, if not upon checkins. And once you got a successful build cycle going again, have a go (in a joking way) at the person who broke the build - when it happens.

Everyone needs to take ownership of the codebase and take responsibility.

To be honest, it also is about having some pride in your craft. If ultimately people don't give a damn if the build is broken, and they don't after being asked to sort it out, it sounds they'd be better off doing some other job.

Wim Hollebrandse
Our build takes several hours, so it's not really feasible to build on every change. I think the problem is not that people don't know the build is broken, just that they don't care.
CodeSavvyGeek
Then you need to restructure it into sub component builds. You can use already built artefacts to reference if their code hasn't changed.
Wim Hollebrandse
If the problem is that people just don't care, then a broken build is the least of your problems.
David G
That too, very good point David.
Wim Hollebrandse
Maybe saying that they don't care is too strong a statement. It might be more accurate to say that they don't understand why it's such a big problem.
CodeSavvyGeek
+11  A: 

Fixing the nightly build should be the highest priority. As you said, if they are broken, they have no value. If people wish to check in code that causes breakage, they should do this on a branch and only merge it in when it is tested.

Mark Byers
+1 - the whole point of having a CI server and nightly build is that you **know** that it builds and passes your tests and hence failing needs to be a *huge* issue.
Murph
+1. There's a post by Jeff @ http://www.codinghorror.com/blog/archives/000052.html talking a little bit about the pragmatic programmer in which they discuss the "Don't live with broken windows" rule. I think a failing test in the suite is definitely a "broken window"
Falaina
+2  A: 

The longer you put off fixing it, the longer it will take to fix.
If it's fixed immediately, the things that cause it to be broken should be fresher in everyone's head. Breaking changes could also be piling up making it that much more of a headache to fix later.

Bela
We actually had this happen. A breaking change was introduced somewhere late in the build, but it wasn't seen until 2 weeks later.
CodeSavvyGeek
+2  A: 

It's critical to get it fixed. The longer you put it off, the more things you're going to find later. How can someone tell if their changes have broken the build, if they don't start with a clean build?

Our standard is to have all our unit and functional tests run "green" on a neutral integration box after a commit. Of course, test-driven development is appropriate to our situation, but may not fit yours. If you're not even able to build the project, there are probably bad surprises lurking in previous commits.

If it's so big that the time it takes to build it is standing in the way of getting it fixed, techniques like breaking it up into smaller projects and continuous integration may help.

Stephen Harmon
A: 

A friend of mine told me about his team that had the Zucchini of Doom. Anyone breaking the nightly build had to display the ZoD on their desk. This vegetable was in a fairly advanced state of decomposition, which sent out the message quite clearly that a broken build was not something to be tolerated.

If the team isn't motivated enough to keep the nightlies building then this is something that should be enforced/encouraged by the managers.

the_mandrill