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

First time XP - 4 weeks in

Expand Messages
  • Sean Higgins
    On the assumption that the rest of you are interested in tales from the front , here s the news from our first-time-semi-XP-project. The project is 4 weeks
    Message 1 of 6 , Sep 1, 2000
    View Source
    • 0 Attachment
      On the assumption that the rest of you are interested in "tales from the
      front",
      here's the news from our first-time-semi-XP-project.

      The project is 4 weeks old today. Allegedly 1 week of preparation and a 3
      week iteration
      to produce our first "system". We've never done XP before and have some
      sceptics
      on board. We picked TestFirst, IntegrateConstantly (is that the word?) and
      DTST.. as the
      principles most-likely-to-succeed-round-here, and made a start. We
      floundered a bit
      trying to think "stories" and "tasks" as opposed to database schemas and
      interface specs
      for the "obvious" system components, and this led to some confusion in the
      first 2 weeks,
      with poor partitioning, some treading on each other's toes, and everything
      depending on
      everything else.

      Now we have a "system" consisting of 2 java servlets that respond reasonably
      to a couple of requests. Basically servlet 1 puts stuff in a database and
      servlet 2
      queries it. There's nothing deliverable there yet, but it does a couple
      of amazing things - compared to any other system I've seen at this stage.

      First amazing thing is the 3 icons on the "build machine" desktop. They
      drive batch
      files that drive perl scripts that drive makefiles.

      One labels all the source in the source control system (VSS) with an
      autoincrementing build number,
      extracts all the source ,
      compiles and javadocs the lot,
      runs all the unit tests (with abrupt termination should one fail),
      jars it and puts it on the right shelf on the servlet runner (JRun).

      Another does all the above, but first it rebuilds the database schema,
      compiles the stored procs, loads up initial table state,
      and runs the SP unit tests. This one needs the DBA to enter a password, so
      isnt for mere mortals.

      The 3rd icon runs all the functional tests. So far these merely issue http
      Get requests to the servlets, with a range of interesting parameters, and
      report the response in a non judgemental way. Scripted in WebL, sorry,
      Compaq Web Language.

      For us the big kick is that it IS all automated, right down the line. To add
      new code to the build, just check it back in to VSS. We haven't had the nerve
      to part from exclusive checkout, so the only way to try a Real Build is to
      check
      in to the main codebase and scurry round to the build machine to try it.

      There is a way to try ALMOST a real build before checking in those latest
      changes.
      Its a command run on each developer's computer. It does the same as the
      first build
      machine icon, with the added change that it also
      1) finds all the files the user has checked out, and copies the local
      version of them
      over the latest VSS sources.
      2) sets an environment variable ("site id") to a user-selected value (we
      use our phone
      extension numbers). This has the effect of limiting the effects of tests
      to a sub-range
      of db records (there is a table of sites, and all other records refer to a
      specific site).
      The unit tests run against the same DB that the build machine uses, but
      addresses a site
      that is effectively "private" to each developer.

      So, on each computer where programs are developed, we can rapidly run the
      entire
      suite of unit tests to see the effect of the latest changes before
      committing them (checking in)
      to the main codebase.

      Even so, the smart thing to do upon checkin, is to scurry round to the
      build machine and verify
      that it still builds/runs all unit tests ok. For those rash enough to skip
      this step, we have
      a very loud and embarrassing silly hat (red/yellow/green with horns) to be
      worn from the time that
      someone else finds the broken build until they get it fixed.

      Thats the picture at end of "iteration 1", we DO have a system (too trivial
      to ship), and it
      is relatively easy to add to it and ensure it still works.

      The sceptics are complaining that we've spent too much effort on
      infrastructure, that we could have
      far more functionality done instead. We haven't got anyone really to do
      pair programming. The
      barriers of code ownership are crumbling however, as people find that they
      needn't wait for
      the "author", and can instead make a change directly. And verify that
      nothing has broken.

      More next time. Hope this helps, and feedback/guidance/wisdom as usual
      always welcome.

      Sean
    • Ron Jeffries
      ... Very good start! Love the automation, wish I had it on my machine at home. Maybe I can learn something about CVS and Python by trying to replicate it. Keep
      Message 2 of 6 , Sep 1, 2000
      View Source
      • 0 Attachment
        At 10:22 PM 9/1/00 +1200, Sean Higgins wrote:
        >More next time. Hope this helps, and feedback/guidance/wisdom as usual
        >always welcome.

        Very good start! Love the automation, wish I had it on my machine at home.
        Maybe I can learn something about CVS and Python by trying to replicate it.

        Keep us posted, and good luck!

        Ronald E Jeffries
        http://www.XProgramming.com
        http://www.objectmentor.com
      • Morris, Chris
        ... Always ... thanks for the post. ... It won t be too long before these 4 weeks are forgotten and the benefits of all the automation will last the rest of
        Message 3 of 6 , Sep 1, 2000
        View Source
        • 0 Attachment
          > On the assumption that the rest of you are interested in
          > "tales from the
          > front",
          > here's the news from our first-time-semi-XP-project.

          Always ... thanks for the post.


          > The sceptics are complaining that we've spent too much effort on
          > infrastructure, that we could have
          > far more functionality done instead.

          It won't be too long before these 4 weeks are forgotten and the benefits of
          all the automation will last the rest of the project.

          I just recently automated my build process which was manually taking about
          45 minutes:

          1. Run Complete Test Suite
          2. Make sure everything is checked in.
          3. Check out each project file and increment the build no.
          4. Check in each project.
          5. Label source files with build number
          6. Move all source files from current folder to backup to ensure a clean
          build from VSS only.
          7. Get snapshot to current, empty folder.
          8. Build all binaries
          9. Re-run test suite
          10. Move binaries out to server, backing up previous build, renamed to
          include build number

          Automated the above takes about 5 minutes.

          We just burned a CD, gave the CD to the 'customer' to do some manual testing
          (no functional testing at the moment) ... found a bug in some code I tweaked
          without unit testing first (dumb). Now I'm unit testing the bug fix -- and I
          need to burn a new CD. Fortunately the new build will only take 5 minutes,
          not 45. It's been more than worth it the 2 days I took automating the build
          process.

          Chris
        • Arrizza, John
          ... very nice. Just a question on why do #1?
          Message 4 of 6 , Sep 1, 2000
          View Source
          • 0 Attachment
            > -----Original Message-----
            > From: Morris, Chris [mailto:ChrisM@...]
            > 1. Run Complete Test Suite
            > 2. Make sure everything is checked in.
            > 3. Check out each project file and increment the build no.
            > 4. Check in each project.
            > 5. Label source files with build number
            > 6. Move all source files from current folder to backup to
            > ensure a clean
            > build from VSS only.
            > 7. Get snapshot to current, empty folder.
            > 8. Build all binaries
            > 9. Re-run test suite
            > 10. Move binaries out to server, backing up previous build, renamed to
            > include build number
            very nice. Just a question on why do #1?
          • Ron Jeffries
            ... One reason is to be sure that you are starting from a clean build that still runs the tests. It s really irritating to have the tests fail, assume it s
            Message 5 of 6 , Sep 1, 2000
            View Source
            • 0 Attachment
              At 08:51 AM 9/1/00 -0400, Arrizza, John wrote:
              >very nice. Just a question on why do #1?

              One reason is to be sure that you are starting from a clean build that
              still runs the tests. It's really irritating to have the tests fail, assume
              it's your fault, dig dig dig, then discover that they wouldn't have run
              WITHOUT your code. Even on C3, this happened once in a while.

              Ronald E Jeffries
              http://www.XProgramming.com
              http://www.objectmentor.com
            • Morris, Chris
              ... Thanks. ... What Ron said is good. I m not on a team at the moment so my primary reason is to catch any stupid bugs before I check in my source code into
              Message 6 of 6 , Sep 6, 2000
              View Source
              • 0 Attachment
                > very nice.

                Thanks.

                > Just a question on why do #1?

                What Ron said is good. I'm not on a team at the moment so my primary reason
                is to catch any stupid bugs before I check in my source code into VSS. It's
                just a minor hassle to go through the check in process (I copy my check in
                comments into a buildlog.txt file), then run the full test suite to see,
                oops! I forgot such-n-such.

                Chris
              Your message has been successfully submitted and would be delivered to recipients shortly.