From: Darren Edmonds <dledmonds@bt...> - 2003-05-26 15:59:42
I'm not sure if I'll be back for the start of the IRC tonight, so I'll
put my findings down in this email (just incase).
First suggestion was to break the build down into smaller parts using
the administration files with CVSROOT. I guess a smaller project is
less likely to run into problems, but with the module dependencies this
won't work for gt2.
The best solution seems to be using an automated build system (maven)
that runs at regular intervals (once an hour say). It runs if there
have been any commits since the last build and emails the errors to a
developers list if the build fails. I remember James saying he'd always
like to have access to a codebase that builds, so on a successful build
the code could be tagged (in cvs).
Next question is who should the failure emails be sent to. I think it
should be everyone who is a developer as these are the people who can
possibly break the build. It was also suggested that at least one
person among the developers should be very familiar with CVS incase its
easier to rollback rather than fix the problem/s. Which developers
could be classed as experienced in cvs?
As projects get bigger the list of developers requires more
administration, so it was suggested that a developer who doesn't
checkout the code in a given period (maybe 3 months) should be removed
from the developers list. This stops someone from trying to commit a
file when they don't have a recent copy of the codebase.
Finally, during the learning process trust, patience, education, and
public shame seems to work :) Perhaps the website should contain the
name of the last person to break the build (in huge letters) to remind
others to take care.
P.S. I didn't have time to look into CruisControl (bank holiday weekend
here in the UK), but maybe this can do everything we need?