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.