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

Re: [agileDatabases] How do you release?

Expand Messages
  • Scott W. Ambler
    I just let go. ;-) Seriously though, at http://www.agiledata.org/essays/tools.html#Sandboxes I m pretty clear about release issues such as this. The closer
    Message 1 of 2 , Aug 28, 2003
      I just let go. ;-)

      Seriously though, at http://www.agiledata.org/essays/tools.html#Sandboxes
      I'm pretty clear about release issues such as this. The closer that you
      get to production the more control you need. A bug in production is much
      more painful than one on a developer's box. Furthermore, the closer you
      get to production the more complicated things get. A developers box may
      not have a complete simulation of the production environment, and thus the
      developers are unable to properly do integration testing, whereas the QA
      environment does simulate this.

      The QA group does need to act in an agile manner, however. They should
      recognize that agile teams are very likely producing much higher-quality
      work than non-agile teams and therefore act accordingly. One process size
      does not fit all.

      Similarly the developers need to understand that the QA folks add
      value. You might find http://www.ronin-intl.com/publications/floot.html to
      be of interest. It shows that there is a lot more to testing that unit
      testing. Don't get me wrong, unit testing is critical, but just because
      you're good at unit testing don't fool yourself into thinking that you've
      got all the bases covered. The pre-production QA/test effort is critical.

      Fundamentally, it's all about risk management. How much effort are you
      willing to invest in the pre-production QA effort to hopefully ensure that
      serious problems don't get past you?

      - Scott

      At 02:33 PM 8/28/2003 +0000, you wrote:
      >Hi, at my company we're re-organizing how we do releases, which are
      >internal releases. We are about 100 people, all at the same
      >location. A "release" generally means that the latest software
      >becomes available on an internally viewable web page.
      >Okay, here is the controversy:
      >The "constant release" group thinks that every developer should have
      >access rights to do a release whenever they choose-- even daily.
      >Unit tests should be catching any bugs anyway, before the code is
      >released A release is done simply by running a script that copies
      >over the latest files checked out from source control, and the script
      >puts a version of the previously released files in a backup
      >directory. That means if a bug slipped through, you just copy the
      >files from the backup directory back to the release directory.
      >The "iteration-QA release" group wants to make releases more
      >difficult. Developers create a special installer, separate from the
      >normal, automated build. A QA person uses this installer and does
      >some acceptance testing on the code. If it passes, the QA person
      >labels the build to enable rollback. Then the QA person releases the
      >code to the company-internal websites, ready to roll back if problems
      >are detected. This QA-controlled release would ideally happen at the
      >end of every iteration, but backlogs may make it less frequent in
      >Okay, I've not done a great job of representing the 2nd group because
      >I'm so heavily on the "constant release" side. But what do you guys
      >do, and what are the merits (or problems) with each approach? Or are
      >there other approaches that we have not even considered?
      >And how does using Windows and COM stuff that requires registration
      >change your answer?
      >Thanks for your insights,
      >To unsubscribe from this group, send an email to:
      >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

      Scott W. Ambler
      Senior Consultant, Ronin International, Inc.

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