Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] Asynchronous versus synchronous continuous integration

Expand Messages
  • Ron Jeffries
    ... Running all the tests in one s sandbox before any kind of commit seems to me to be basic, but perhaps it needs saying. I think we re talking about what
    Message 1 of 117 , Jan 1, 2005
    • 0 Attachment
      On Friday, December 31, 2004, at 6:38:20 PM, Steve Berczuk wrote:

      > On Fri, 31 Dec 2004 18:16:05 -0500, Ron Jeffries
      > <ronjeffries@...> wrote:
      >> I was still talking about Jason's proposal to run the tests
      >> automatically and not commit the stuff that doesn't build, bouncing
      >> it back to the devs. Have I missed a turn somewhere?
      >>

      > I think so. Jason (and please correct me if I misunderstand!) was
      > talking about DEVELOPER pre-commit tests followed by MORE EXTENSIVE
      > post-commit tests in the integration environment. The Post Commit
      > build and test happens asynch, but only after there is a synch
      > developer step to be somewhat sure that the build is not broken...
      > Maybe it was a fork in the road rather than a turn (a la Yogi Berra:
      > If you see a fork in the road, take it -- you'll end up in the same
      > place!)

      Running all the tests in one's sandbox before any kind of commit
      seems to me to be basic, but perhaps it needs saying.

      I think we're talking about what happens after that: whether one
      does as Beck and Jeffries et al. recommend, and builds on the build
      machine, or whether one throws one's code at the asynch process
      Jason describes.

      When you and I walk over to the build machine and build, we are
      focused on that, and yet have an opportunity to decompress, to talk
      over what has happened, and to look out the window if any.

      When you and I throw our software over the wall to the asynch build
      and go on coding -- which is the avowed advantage of the idea as I
      understood it -- then when the build barfs, we aren't "there".

      That's my concern. If a team wants to wind up there, I guess it's OK
      with me. If they're large enough, it's more likely to be needed. I
      just don't think it's the basic starting point: it might be a point
      you'd be driven to, but after four years of manual sync on a 14
      person team, I'm not sure why. Maybe we were just dull.

      Ron Jeffries
      www.XProgramming.com
      For me, XP ain't out there, it's in here. -- Bill Caputo
    • Chris Dollin
      ... I have learnt the hard way the following rule: never check significant modifications in (in our case, to SourceForge) ten minutes before going home time on
      Message 117 of 117 , Jan 18, 2005
      • 0 Attachment
        On Monday 17 January 2005 17:26, Jeff Grigg wrote:
        > > --- Robert Watkins wrote:
        > >> Personally, I find long builds offensive, _even if they
        > >> aren't causing me any pain_. The "Build Successful"
        > >> message is feedback, and I want to reduce the time that
        > >> feedback takes to arrive.
        >
        > --- Ron Jeffries <ronjeffries@X...> wrote:
        > > In what way are they offensive?
        >
        > Let's say it's Friday. At 5:23 P.M. I just checked in my changes
        > and I want to go home. But what if it takes Cruise Control 15
        > minutes to run all the tests? Should I wait until it completes,
        > confirming that my changes were good, before I leave for the
        > weekend? What if it takes half an hour? What if it takes an hour?

        I have learnt the hard way the following rule: never check significant
        modifications in (in our case, to SourceForge) ten minutes before
        going home time on a Friday, or indeed any other day of the week.
        Because, even if all the tests pass, even if you updated just recently,
        *that* will be when you forgot to cvs-add the new tiny class, and when
        the connection to SF is taking place along a stretch of salty string,
        and the fetch-code-into-paranoia-directory step takes forever, and
        *then* you discover there's a problem, and you've come in by train
        not car so an extra ten minutes isn't fatter traffic-jams and twenty
        minutes extra on the commute, it's getting home an *hour* later ...

        --
        Chris "electric hedgehog" Dollin
      Your message has been successfully submitted and would be delivered to recipients shortly.