I'm in this boat, we use very few VMs and mostly run on bare metal, the fixed cost of migrating data and retesting on an entirely new stack when the hardware is replaced at end of support lifecycle also covers testing the changes due to RHEL upgrades. It may be batching up a lot of change at once, but it's also a project that has a budget and can be scheduled, we know some amount of maintenance work will be necessary to accommodate changes, that balances against all the surprise breakage we don't have to worry about during the normal lifecycle, aside from a recent functional change of perl-DBD-MySQL being linked against Oracle libmysql instead of MariaDB libmariadb as it was previously, we very very very rarely see any negative outcome from regular patching and don't need to worry about bad surprises. Automated testing would be useful and better, sure, but it isn't necessary for survival as the breakage risk is low.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。