[rt-users] Upgrade strategy?

[Sheeri Kritzer]

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 at tufts.edu


Quoting Jesse Vincent <jesse at bestpractical.com>:

> 
> 
> 
> On Wed, Feb 02, 2005 at 09:12:09AM -0600, Bob Goldstein wrote:
> > 
> > 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
> _______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
> 
> RT Administrator and Developer training is coming to your town soon! (Boston,
> San Francisco, Austin, Sydney) Contact training at bestpractical.com for
> details.
> 
> Be sure to check out the RT Wiki at http://wiki.bestpractical.com
>