[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [wtp-jsf-dev] Build Breaker Solution
|
> a. shouldn't be necessary with such a nice development environment as
Eclipse :)
True, but a successful local build in Eclipse means nothing, since we
can't do local builds ourselves using the make system.
> b. encourages some developers to overly depend on it to make sure
they don't break anything
> (that is, they should be sure of this before even putting into head,
ideally).
This can be reduced by implementing an accoutability policy and a
penalty for breaking the build. Good penalties I have seen before include:
a) If you break a nightly, you bring donuts on Friday
b) If you break a nightly, you get stuck with some unpleasant task for
the week like build smoke tests.
> c. gives a false sense of security since there's a large number of
cases that work fine
> from head, but would not work from released/versioned builds.
But we would still have the weekly integration and team leads would
still be accoutable for meeting release targets.
> d. Continuous builds, as we have, should be perfectly equivalent or
even better
> since they run even more frequently than a nightly build.
Do they run against HEAD? You are right, a continuous build at HEAD
would be even better. At a previous place I worked, the core team had a
build cluster that automatically built and unit tested every single
commit transaction at HEAD. Breaking changes were forcibly backed out
if they weren't addressed within three hours of detection. Believe me,
that is very good incentive to be sure that you are committing working code.
--Cam
