Ron Jeffries wrote:
> If it works, do it. And write it up.
>
> The smaller the time-frame between commits, the more I'd like to
> have an automated setup. //But I want one that pushes code to all
> the other developers, keeping the sandboxes synchronized.//
That's an interesting concept; one that's not even possible in a lot of
SCMs (you could probably do it in ClearCase with its dynamic views). In
most situations, developers would need to fetch changes themselves.
However, I think there's an interesting dynamic going here: the more
frequently people check in, the less they should need an automatic
synchronisation mechanism, because they should do an update as part of the
commit process.
> I think that the manual check in is a team-building and
> experience-building practice. A team with existing habits of
> throwing their code at the build and waiting until Friday will, I
> believe, do well to experience building, and its impact, directly,
> hands on, before going to some automated scheme.
Definitely; any automated system that does builds and is basically ignored
will become a crutch for the team. Focusing on keeping the build healthy is
important, and is a key aspect of the continual integration practice after all.
> My reasons are primarily social, just as they are for wanting
> planning done on cards rather than in a software tool. First I'd
> like to get the society right, and all the automated things that
> most pre-Agile developers have used have set up almost exactly the
> wrong habits.
Any continual build system is a tool that needs to conform to the team,
rather than the other way around.
If I was part of a team that was trying to adopt XP, particularly the
continual integration practice, then I would enforce a strict "Build
locally first; never break the continual build" policy. In this scenario,
the continual build simply helps to act as a traffic cop of sorts, giving
you another way (besides direct observation) of knowing if people aren't
running the local builds.
However, with a slightly more mature team, a continual build server can
supplement the manual builds effectively. I wrote on my blog recently on
this topic, and one of the observations I made is that the new "10 Minute
Build" practice is very much a relative timeframe. If you have an
integration cycle of a few hours, a 10 minute build is probably about
right. If your integration cycle is 30 minutes, 10 minutes is far too long.
However, you can gain benefit from running a subset of your build locally,
leaving the more timeconsuming aspects (such as code coverage, dependency
analysis, documentation generation, and other housekeeping activities) to
the continual build server.
One of the principles of CruiseControl, BTW, is that the developers should
have access to exactly the same build script, and should be able to run the
build locally. In my setup, I make the associations explicit: I have a
"build" target that developers should run, and a "cruise-build" target that
CruiseControl runs (but developers can). Part of the process of setting up
a work environment is running the "cruise-build" target; that way, you know
the local work environment is fully configured. This principle, to my mind,
is one of the major strengths of CruiseControl over other similar systems,
which seem to end up warping your build scripts to suit.
An interesting aspect to a continual build server in a mature team is that
you should expect the occasional build failure; the server exists to be a
time saver, by taking some work off your hands. That work doesn't have a
guaranteed success rate, so it _should_ break occasionally. If it never
breaks, then your team isn't letting the server take enough work away from
them. The point of the continual build server isn't to ensure that the
build is always good; it's to let you know wether the build is good or not.
Ensuring that it's always good is the team's responsibility, and that can
not be abdicted to a set of silicon chips.
--
"Software is too expensive to build cheaply"
Robert Watkins http://twasink.net/ [EMAIL PROTECTED]
To Post a message, send it to: [EMAIL PROTECTED]
To Unsubscribe, send a blank message to: [EMAIL PROTECTED]
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
