2009/2/24 aslak hellesoy [email protected]
going to amend it first thing tomorrow morning.
Because the longer you wait, the more your code will diverge from your
teammates’. If you don’t commit often you rob them of the opportunity
to reduce merge hell.
This is the money line for me.
There’s a lovely CI pattern I’ve seen in the centralised SCM world (with
Java, but that’s less important) that I’m surprised hasn’t been
mentioned.
Before I describe it I’d like to take this back to first principles.
The point of continuous integration is to keep each individual
integration
small and avoid less frequent big integrations, because that’s where
the
pain happens. Syncing up once per story or feature, which could easily
be
several days work, strikes me as a retrograde step. The fact that DSCMs
like
git or hg allow you to do this doesn’t make it a good thing. There are
many
fantastic reasons to use DSCM - modelling IBM Rational ClearCase “best
practice” usage patterns shouldn’t be one of them.
Anyhoo, it seems to me the problem we are discussing is the coupling
between
checking in an unfinished scenario and failing the build. The solution
I’ve
seen - scaling to projects with tens of developers and thousands of
scenarios - is to separate in-progress features from finished ones, and
build everything.
If an in-progress scenario fails then the build carries on. If a
completed
scenario fails it causes the build to fail. There is a nice corollary to
this whereby you fail the build if an in-progress scenario accidentally
*
passes*. This is because you usually want a human to find out why. In
cuke-land you would do this at a feature level rather than a scenario
level
since the convention is to have one feature (with multiple scenarios)
per
file.
Marking a feature as done can be as simple as moving it between two
directories (called in-progress and done), renaming the feature (from
openid_login.in-progress to openid_login.feature) or having an
:in_progresstag on a feature until it’s done.
In Java-land I prefer the first model because I can point the same junit
task at either the in-progress or done directories and just change the
failOnError flag.
In any case, I would strongly encourage changing the build so you can
integrate continuously - i.e. git push as frequently as you normally
would -
knowing the build will remain clean as long as you mark your unfinished
work
as in-progress. Lightweight, cheap branches are great for local spikes,
exploration of unfamiliar code and any number of other incidental
activities, but I’m deeply sceptical that they should form part of your
core
workflow.
No doubt once this becomes the norm and Rational are laughing up their
sleeves I’ll live to regret saying that 
Aslak
Cheers,
Dan
The understanding is tough…