[rspec-users] [cucumber] Cucumber and CI
hayafirst at gmail.com
Wed Mar 4 12:31:28 EST 2009
Great writing. Thanks
On Wed, Mar 4, 2009 at 5:25 AM, Dan North <tastapod at gmail.com> wrote:
> 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>
>> > 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
>> >> 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_progress tag 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 :)
> rspec-users mailing list
> rspec-users at rubyforge.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rspec-users