Any advice for 3.2.0->2.4.0 strategy?
In the past, I’ve installed the new code in a new directory and
created two urls, so I could run either the new code or old at
the drop of a click, both using the same database.
I liked the ability to use the production database, because it’s
much more likely the new code (and my mods to it) will be tested.
However, bold is not the same as foolhardy. I notice there are
schema changes that involve deletion of columns, as well as
addition. Even if I only do the additions (to start), I’m
guessing that running the old code (which won’t populate the new
columns) and new code (which might become unhappy at seeing new
tickets with null values in these new columns) might not be
overly wise.
Plan B is copy the prodution database, upgrade code-and-db,
and test on the testbed. Safe, but it won’t be tested
as thoroughly by the staff. Any suggestions (just technial
ones, please. Don’t tell me to beat the staff with a stick 
bobg
Any advice for 3.2.0->2.4.0 strategy?
In the past, I’ve installed the new code in a new directory and
created two urls, so I could run either the new code or old at
the drop of a click, both using the same database.
That’s a reasonable strategy for minor version bumps but won’t work
between 3.2 and 3.4.
However, bold is not the same as foolhardy. I notice there are
schema changes that involve deletion of columns, as well as
addition. Even if I only do the additions (to start), I’m
guessing that running the old code (which won’t populate the new
columns) and new code (which might become unhappy at seeing new
tickets with null values in these new columns) might not be
overly wise.
Right. I suspect that it might be possible to do with a database with
read/write views. But it’s not something we planned for, tried or
recommend.
Plan B is copy the prodution database, upgrade code-and-db,
and test on the testbed. Safe, but it won’t be tested
as thoroughly by the staff. Any suggestions (just technial
ones, please. Don’t tell me to beat the staff with a stick 
That’s the right thing to do. Perhaps it’s worth offering some sort of
carrot to the staffmember who best-tests the new system or finds the
most issues on the testbed server.
Jesse
Bob,
We have what Jesse suggests – a test server (which, when it’s not being used
for testing, is happily replicating the production database, so we have a
failover RT server and database just in case).
When we upgrade, we break replication, upgrade the test server, and test. Our
testing does not have users test it – if they did, they’d be putting stuff into
tickets, and we don’t propogate that information back, just in case there is a
problem with the newer version.
Anyway, we have a testing checklist, which is quite long. It has on it
everything from bugs we’ve seen in the past (every time we upgrade we test to
make sure that you can’t merge 2 tickets into each other, making sure that
certain scrips still work, etc) and our site customizations (history with most
recent on top, history itself on top and the basics/links/people/etc on the
bottom, etc). The testing checklist really does test everything, refers to
specific RT bugs we’ve had in the past (what we’ve found and customer
complaints). We add to it whenever we do a site customization or find and fix a
bug. We check it whenever we do an upgrade (we diff the files in the local
directory with their counterparts in the html directory, just in case we
modified code and didn’t put it in the test plan).
Hope this is helpful. It has been really helpful to us, especially because we
know we’ve gotten all the bugs we’ve had before, we don’t revert back to a
non-customized version, etc. The testing plan also has things like “e-mail a
ticket into rt” and “resolve using RTFM” to find major bugs.
-Sheeri Kritzer
Systems Administrator
University Systems Group
Tufts University
617-627-3925
sheeri.kritzer@tufts.edu
Quoting Jesse Vincent jesse@bestpractical.com:
At Wednesday 2/2/2005 10:34 AM, Sheeri Kritzer wrote:
Anyway, we have a testing checklist, which is quite long.
Sheeri,
I’d be interested to see the checklist, if you’d be willing to share it.
Thanks,
Steve