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

Re: An XP Starting Place: The Build

Expand Messages
  • davenicolette
    Hi Mike, Great story. Here are some additional examples that I think support your point:
    Message 1 of 2 , Aug 20, 2008
      Hi Mike,

      Great story. Here are some additional examples that I think support
      your point:


      --- In extremeprogramming@yahoogroups.com, "Mike Hill" <mike@...> wrote:
      > Here's a frequent noob team problem: Not stabilizing the build and the
      > tools.
      > This morning, I did a virgin build[1] of IL's Greatest Hits. (GH is the
      > program that serves our eLearning content.) In most projects, I do
      > builds with great regularity, but the truth is I rarely do it with
      GH, it's
      > just that I trashed my existing build with a broken Ganymede
      install, so I
      > had no choice. Anyway, fresh out of the box, with a valid Ganymede,
      and a
      > one-step pulldown of source, I built and ran. All was well. We
      build using
      > ant, with the microtests getting built, but I'm a big fan of the
      green bar,
      > so I re-ran them manually from inside eclipse. I got two red
      microtests. I
      > sent out an e-mail to our dev list, and got an immediate reply. (A
      > re-run of the tests solved the problem: there's a dependency error
      > there somewhere, but as an end-user, I didn't investigate further.)
      > So, all of this is only interesting because of the starting
      conditions. It
      > only works 1) because we have very high confidence that our microtests
      > always pass, and 2) because there's no handle-jiggle[2] in the build
      > process, and 3) because we are zero-tolerance in having things that way.
      > If you're new to agile practice, and you want to know where to
      start, one
      > place is to start here. Unify the team around the tools and their
      > installation. Create a one-step process for bringing the entire project
      > down to a tool-equipped box. Create a one-step process for
      identifying and
      > running the tests. Create a community will that says "anything that
      > perfect from a virgin build is a show-stopper".
      > Just morning thoughts while I wait for my client team to build. :)
      > Hill
      > Wanna master TDD? Try <http://www.industriallogic.com/elearning>
      > [1] A "virgin build" is a build on a machine that has the tools
      ready, but
      > has no prior version of the code. In our system, that means using
      > 'replace with...' menu. Frequent virgin builds are a good way to
      > your build-tuning.
      > [2] Ever experience a toilet that keeps running after the flush?
      Its owner
      > will tell you "just jiggle the handle". Handle-jiggle is stuff like
      > change the .cfg file so it points at X", or "just make sure there's
      a valid
      > certificate in the Y directory", or "you have to manually log in to
      Z before
      > you start". Handle-jiggle is bad.
      > [Non-text portions of this message have been removed]
    Your message has been successfully submitted and would be delivered to recipients shortly.