## Peter J. Holzer (hjp-pgsql@xxxxxx): > * 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
