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

Re: [XP] Asynchronous versus synchronous continuous integration

Expand Messages
  • Steve Berczuk
    On Sat, 1 Jan 2005 11:03:09 -0500, Ron Jeffries ... Hmm, Why isn t there a place in the process for a set of exhaustive tests that use many resources to ensure
    Message 1 of 117 , Jan 1, 2005
    • 0 Attachment
      On Sat, 1 Jan 2005 11:03:09 -0500, Ron Jeffries
      <ronjeffries@...> wrote:
      >
      > On Saturday, January 1, 2005, at 10:50:09 AM, Steve Berczuk wrote:
      >
      > > But what if you have a "complete" set of tests that takes, say, an
      > > hour....
      >
      > This is the bug. We should fix it.

      Hmm, Why isn't there a place in the process for a set of exhaustive
      tests that use many resources to ensure that the application works
      correctly? If you had such tests it is plausable that they may take a
      long time. I agree that the tests that developers run to ensure that
      the build works shoud be quick. But I think that you would want to run
      more exhaustive tests. And run these asynchronously.

      I'm trying to describe a layered approach:
      1. While coding: Incremental builds and Unit Tests for code you are working on.
      2. Before Check in: Update from Codeline, Full Build (when possible)
      but perhaps not from a clean checkout, and the reasonable set of tests
      that run quickly.
      3. After check in: Automated FULL BUILD (from a clean checkout),
      FULL set of COMPLETE tests.

      Perhaps what differs between what I am saying and what Ron is saying
      is that there is also
      a 3(-) step where we run a full build from a clean checkout, but the
      quick set of tests, on the integration machine? (and wait for the
      results?) I think that, in practice, you would see the problems from
      the first step of the integration build quickly enough to make timely
      changes...

      Steve


      --
      Steve Berczuk | steve@... | http://www.berczuk.com
      SCM Patterns: Effective Teamwork, Practical Integration
      www.scmpatterns.com
    • 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.