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

Re: [XP] Asynchronous versus synchronous continuous integration

Expand Messages
  • Robert Watkins
    ... Kent, Why would you assume that integration is finished when you release your code? It is certainly feasible to say that integration is not finished until
    Message 1 of 117 , Jan 1, 2005
    • 0 Attachment
      Kent Beck wrote:
      > My concerns with the integration process are efficiency and learning. When I
      > am notified of a build breakage after the fact, I have to interrupt my
      > current task, take a while to remember what I was working on, and then take
      > a while to get back to my task. That seems inefficient to me. It's worth ten
      > minutes of waiting to avoid eleven minutes of task switching (YMMV). When I
      > find a problem right away, not only do I fix it faster but I have a better
      > chance of learning not to make that kind of problem in the future.

      Kent,

      Why would you assume that integration is finished when you release your
      code? It is certainly feasible to say that integration is not finished
      until you get the build success notice.

      I encourage people to run builds locally to get confidence levels to a high
      point, like the high 90s. They can then release the changes, and the build
      server goes to town. Integration is finished when the build server says its
      done. The idea here is that if it will take me an extra two minutes to get
      100% confidence, but I've already got 95%, then it's not worth it for me to
      spend those two minutes now.

      In the local vs remote build scenarios, the local build should focus on the
      most common reasons for failed integrations - the compile & test phase. The
      remote build should focus on other things, predominately QA activities.

      > I don't see this as "manual" integration. I find the Eclipse three-way
      > synchronization to be very efficient in the normal case where there are no
      > conflicts and very helpful when there are conflicts.

      The Eclipse synchronisation view is absolutely fantastic. Being able to
      easily see the changes you're going to pull down solves one of the biggest
      limitations of using CVS.

      > I very much like your point about failures at later stages turning into
      > tests/steps in earlier stages. Ideally I'd like to avoid staging altogether,
      > but while learning to make this safe the adaptive strategy you suggest seems
      > both efficient and effective.

      Every build failure is a learning opportunity. Being able to analyse
      patterns of build failures is an even better learning opportunity.

      Robert.

      --
      "Software is too expensive to build cheaply"
      Robert Watkins http://twasink.net/ robertdw@...
    • 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.