Build system thoughts

[Greg Ward]

On 08 December 2008, Bill Barry said:
> I was thinking about CI and was wondering what everyone here thought 
> about the following working practice designed for small to medium teams 
> (probably around 8 to 30 people):
> 
> 1 outgoing repo (call it stable)
> 1 "centralized" repo (call it central)
> developers maintain their own copies of the central repo, all have push 
> access

Sounds good so far.  (I.e. I have been thinking along the same lines for
my group, currently 25 developers working on 3-10 projects [depends how
you count the projects]).

[...]

> there would be a stable repository maintainer role who would:
> hg pull
> hg up -C default
> hg merge -r "featurename"
> (possibly dealing with conflicts)
> hg ci -m "merging in featurename message"
> hg push
> hg push -r default stable

This is where you lose me.  Our company has a culture that
developers do their own merges, and as the guy who would be stuck
merging everyone else's features/fixes if we changed that, I am strongly
in favour of it.  ;-)

(Plus, who better to resolve a conflict than the person who wrote the
code that's conflicting?)

The other thing that concerns me a bit about your proposed workflow is
the lateness of integration.  Currently, we do most new feature work
right on the trunk of our CVS repository.  Since we're using (ugh) CVS,
we only create development branches for features that would destabilize
the tree for many days.  The advantage of everyone working on the trunk
is that we find bad commits pretty soon: the guy next to you updates and
can no longer compile.  Oops.  Better fix it *now*.  (Of course that is
sometimes a disadvantage too.)  And we only need one nightly build of
the trunk, not of every active dev branch.

I can see the point of CI builds of active dev branches, but I don't
like 1) having one gatekeeper responsible for merging other people's
features and 2) the fact that that merge happens late, when it's getting
close to release time.  IMHO features done on a dev branch should be
merged to the trunk as soon as the responsible developer(s) says they
are done.  Then we can all eat each other's dogfood well before branch
day.

> So what are your thoughts? And is there any tools either already in 
> existence or under current development which could fulfill this CI 
> process role (everything else appears doable right now)?

You should definitely take a look at Buildbot.  It's a great CI
framework.  Takes a bit of work to wrap your head around it, but once
you do you can do some neat stuff.

        Greg