## Peter J. Holzer (hjp-pgsql@hjp.at):
> * Update frequently. That reduces the risk of needing a package which
> has since been deleted from a repo, but more importantly it makes it
> easier to pinpoint the cause of a conflict.
This. Plus: make sure you can re-create any machine in a fully deterministic
manner - that way, you can easily create a test environment to match
production (minus RAM/CPU/storage) for testing upgrades beforehand.
Rationale: experience shows that using Test as "first stage" and carrying
changes forward to Production results in a "contaminated" test environment;
before long, results of failed experiments have accumulated on Test,
Production and Test are diverging, and at that point Test has lost it's
purpose.
(For some people, that's a point for containerization: you don't change
a running container, but package a new one. Other environments have so
much Production with all the redundancy etc that they can "test in
production" and just scrap-and-replace failed tests, but that's not an
option if you have just a handful of systems.)
Regards,
Christoph
--
Spare Space
