Jim Shore wrote about why he
doesn't like Cruise Control. I agree to some extent with his points that the
reason teams use it is to catch build errors and deal with "slow" builds. Having
implemented both Draco.NET and CruiseControl.NET
and toyed with FinalBuilder I am
not overly impressed with any of them. My impression is that I spend way to much
time fiddling the build server for the value added. I will say that I would
still implement a build server for any team for the single reason that "people
are fallible".
People forget to commit related changes, or add files to CVS, run tests, etc.
The build server never does.
I didn't see a way to add comments to Jim's post, so I'll comment here.
Jim seems to imply that his builds don't break:
"if your build is failing a lot, you have a clear opportunity to improve...Try to get to the point where, like me, you don't like CruiseControl... because you don't need it"
I'd be interested in how he ensures that his builds don't break. As you say, Wayne, people are fallible. I see CC as the runt developer in the corner, who has to be hand-held through every build step. If CC can build it, then anyone can.
As for slow builds, I absolutely agree that every effort should be made to speed them up. It's one of my biggest gripes. But sometimes things really do take time (end-to-end testing with full data setup/teardown for one) and aren't much fun to watch. I think in those cases, developers should run an "express" build and the rest should be handed off to the build server.
But the real issue is: why *not* have a build server? The answer at the moment seems to be that they're all a bit clunky to set up and maintain, but what if they were idiot-proof?
Jim (ThoughtWorks, for the record)
Well if you're going to check in code that you know works then you have to run the tests locally first. So why bother doing it again on a build server? I tend to agree it doesn't make a ton of sense.
Yes, but how many times have you heard the comment:
"But it worked on my machine"
[how many times have you heard the comment:
"But it worked on my machine"]
zackly.
Jim
I don't think of my CruiseControl server as being there for the developers, but more for the management. Build servers put the "Assurance" in "Quality Assurance"
Kind of interesting that you cann't comment on James's blog :-) Yes, In a perfect world our unit tests would run instantaneously after an instantaneous compile on our desktops. Of course our code would include all the latest sourcecode from the source code respository. Oh, yeah, and when a unit test did fail due to a dependency of someone else's recent check-in (say maybe 200+ components) the developer that just attempted the build will somehow be responsible?
Because I view the build process as the manufacturing step, the build server should be viewed as automating the factory. It clearly documents what it takes to manufacture the source into a deployable product. In our world the build scripts are versioned as part of the build process.
A build server solves another problem for us. We use third party components that have developer licensing restrictions (node locked). The build server allows us to centralize the licenses for the components that only 1 or 2 developers have a need to work on. Every desktop does not need a license to perform the compile.
The point is... it's not a perfect world. Software development is messy and very human process.