updates on production machines

[Tom H]

On Wed, Dec 8, 2010 at 10:19 AM, Cybe R. Wizard
<cyber_wizard at mindspring.com> wrote:
> On Wed, 8 Dec 2010 09:37:45 -0500
> Tom H <tomh0665 at gmail.com> wrote:
>
>> On Wed, Dec 8, 2010 at 6:51 AM, Matt Johnson <johnsonmlw at yahoo.com>
>> wrote:
>> >
>> > I've been following the forums for a little while and there seem to
>> > be quite a few 'show-stoppers' that arise when folks update their
>> > machines (remaining in the same release). I think I've been blasé
>> > about applying updates nightly. Reading the issues raised, I'm
>> > (perhaps appropriately) anxious about applying any updates on
>> > production machines I've got here. I've probably got the wrong end
>> > of the stick.
>> >
>> > Are these issues pretty rare? How do people protect against issues
>> > caused by updating packages?
>> >
>> > * Full back up / restore (in which case I'd modify my behaviour to
>> > only apply updates when I could protect the time required to
>> > perform a full restore)
>> >
>> > * Some sort of dry run or easy way to roll back?
>>
>> At the very least, test in a VM before deploying.
>>
> That doesn't always mean anything as the VM will likely have different
> 'hardware' than the real machine.  For instance, I can't test/use the
> nvidia software in a VM because the default virtual hardware isn't
> nvidia.

That's why I said "at the very least".

For X-less servers, VMs are good enough - no need to test amd/nvidia
or compositing.

Anyway, in our environment, updates are tested on dedicated test
boxes, rolled out to dev then uat then prod - and it's not necessarily
fool-proof.