Re: [agileDatabases] How do you release?
- 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?
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.