[rspec-users] [cucumber] Cucumber and CI

Dan North tastapod at gmail.com
Wed Mar 4 06:25:24 EST 2009

2009/2/24 aslak hellesoy <aslak.hellesoy at gmail.com>

> On Tue, Feb 24, 2009 at 10:30 AM, Rob Holland <rob.holland at gmail.com>
> wrote:
> > On Tue, Feb 24, 2009 at 9:17 AM, Matt Wynne <matt at mattwynne.net> wrote:
> >
> >> You can even use git commit --amend to commit on red (e.g at the end of
> the
> >> day) and then change that commit later.
> >
> > While I think commit --amend is very useful, I'm not sure why you'd
> > bother to commit at the end of the day, knowing full well you were
> > 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

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

No doubt once this becomes the norm and Rational are laughing up their
sleeves I'll live to regret saying that :)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20090304/f7cb6a43/attachment-0001.html>

More information about the rspec-users mailing list