Joshua Kramer wrote:
>> So how do you package such a thing in RPM so it can permit both new and
>> old instances to run simultaneously while you do all of this required
>> testing? I suppose these days virtualbox is an almost-reasonable answer
>
> I think this discussion is a reflection of our different environments. :)
I see it as a generic problem with RPM packaging/deployment that you are
forced to work around by maintaining duplicate equipment.
> On my websites... when 8.3 came out, I downloaded it to a test machine. I
> then did a dump of the production data from 8.2, and did an import into my
> 8.3 test machine. After pointing an Apache dev instance at the test
> database, I could verify that my applications still worked, and make any
> code changes that were required.
That's great if you have a test machine for every application. For an
important production web site it kind of goes with the territory.
> After I had a test/dev environment that was stable under 8.3, I planned
> the migration: 1. Dump 8.2; 2. Shutdown 8.2 and remove packages; 3. Move
> 8.2's data directory; 4. Install 8.3 packages, and initdb; 5. Import data
> made during the dump and start db; 6. Migrate code changes to web server.
> After things baked for a week and there were no errors, I deleted the old
> 8.2 data directories.
What would you do for something simple that doesn't justify buying a
duplicate machine, yet is probably even more likely to break from a
version change?
> I realize that this is much more difficult if you're using a VM on a web
> host that only allows one machine. Is this the type of environment that
> is constraining you?
I'd just like to see a realistic approach to updates via packages.
> As long as you can test your application under the
> new database version to make sure it's OK, the migration can be done on
> one machine. But let me ask: in what case would you not want to test your
> application against a new database version?
I do want the ability to test while still running the old version. I
just don't see how that is possible with any RPM-deployed package
without having duplicate hardware or virtual machines. Postgresql makes
a good example because the conversion needs both new and old code
present for different steps, and 8.2->8.3 especially so because some
implict casts were removed that can break client code in odd ways, but
the principle is the same for any change where you want to know the new
version works in your environment before the old one is shut down. If
you build from source you can make it use different locations and ports
and run concurrently, but with RPM binaries you can't.
--
Les Mikesell
lesmikesell at gmail.com