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

RE: [XP] Asynchronous versus synchronous continuous integration

Expand Messages
  • Appleton Brad-BRADAPP1
    ... What he just said! ... Clearcase can do this, by virtue of its virtual filesystem. I cant recall coming across a developer that ever preferred it to happen
    Message 1 of 117 , Dec 31, 2004
      Steve Berczuk writes:
      > This is basically the idea behind the dependency structure in
      > the SCM pattern language between Private System Builds,
      > Integration Builds, and the various kinds of tests.
      >
      > http://www.scmpatterns.com/book/pattern-summary.html
      > or
      > http://www.scmpatterns.com/book/refcard.html
      > with the emphasis on more frequent integration, perhaps at
      > the expense of "better" yet longer running tests.... (Note,
      > that I probably need to better define the distinction between
      > smoke, unit, and regression tests)

      What he just said!

      > > The smaller the time-frame between commits, the more I'd
      > like to have
      > > an automated setup. //But I want one that pushes code to
      > all the other
      > > developers, keeping the sandboxes synchronized.//

      Clearcase can do this, by virtue of its virtual filesystem.
      I cant recall coming across a developer that ever preferred it to happen this way rather than having control over when their own sandbox (workspace) gets updated. Usually they just want notification to alert them when it happens. Most extreme case is they want some kind of dialog/alert to pop-up to say "Joe has commited his change "foobar" to the codeline - would you like to automatically update your sandbox to the latest state of the codeline?" with options like yes, no, and "more info" where I can look at a summary of joe's changes, and "drill-down" to view a diff-package if desired.

      > We've had this discussion before. The trick is to not be
      > disruptive. I suspect ALERTING someone that there was a
      > change should be good enough (and we all update from the
      > repository every few minutes when we're not actively coding
      > anyway, right ? ;) )

      We have an article on this as well, regarding "Codeline Merging & Locking: Continuous Updates and Two-Phased Commits"
      (See <http://www.cmcrossroads.com/articles/agilenov03.pdf>)
      it talks about a post-commit notification to implement such alerting so others can do "Continuous Workspace Update", as well as several different flavors and levels of synchrony/asynchrony to ensure proper-commit protocol and codeline consistency/integrity for a two-phased codeline commit.

      --
      Brad Appleton <brad@...> www.bradapp.net
      Software CM Patterns (www.scmpatterns.com)
      Effective Teamwork, Practical Integration
      "And miles to go before I sleep" --Robert Frost
    • 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
        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.