问题：
我知道很多人对频繁的版本变更不太满意。尤其是当您坚持使用的最新版本的 PHP 或 MySQL 不再存在于您的存储库中（在我的情况下是 REMI）时，但您必须安装一个新服务器，其中包含一些版本稍低（较旧/较早）的 PHP/MySQL 软件包，因此存储库中可用的版本会更低。
大多数时候，我们都在 Centos 5.8 GNU/Linux x86_64 操作系统上使用典型的 Apache、PHP、MySQL 的最新版本。
但是现在我们的 QA 团队需要花费大量时间来测试所有项目与新版本的兼容性，新版本的发布速度非常快，当我们获得 QA 团队的批准来更新 PHP 和/或 MySQL 和/或安装使用该特定版本的新服务器时，我们发现它已经过时，现在它已被更新的版本所取代。
尤其是当 McAfee PCI Compliance 表示我们的网站使用了有潜在危险的 PHP 版本并强迫我们使用较新版本的 PHP 升级所有服务器时，我们就会感到特别担忧。
目前我们的默认工作环境由以下人员组成：
操作系统：
CentOS 版本 5.8（最终版）Linux censored.example.com 2.6.18-308.4.1.el5 #1 SMP 2012 年 4 月 17 日星期二 17:08:00 EDT x86_64 x86_64 x86_64 GNU/Linux
阿帕奇：
服务器版本：Apache/2.2.3 服务器建立时间：2012 年 2 月 23 日 21:16:56
PHP的：
PHP 5.3.13 (cli)（构建于：2012 年 5 月 9 日 16:20:57）版权所有 (c) 1997-2012 The PHP Group Zend Engine v2.3.0，版权所有 (c) 1998-2012 Zend Technologies 与 eAccelerator v0.9.6.1，版权所有 (c) 2004-2010 eAccelerator，由 eAccelerator 提供
MySQL的：
mysql Ver 14.14 Distrib 5.5.23，适用于 Linux (x86_64)，使用 readline 5.1
可能的解决方案：
本地存储库/旧版本镜像 只需制作最新安装软件包的自定义存储库快照，这样我们就可以使用相同的软件包设置/安装新服务器，即使它们不再受支持，我们也可以继续前进。优点和缺点：安装简单，使用相同的 YUM 命令，但它不会破坏与可能更新的其他系统软件包的依赖关系，这样会不会有隐藏的水石？
从源代码编译 忘掉 YUM 和 RPM，使用静态编译版本，回到使用 GCC 编译器和依赖地狱的美好旧时代。优点和缺点：不再依赖于存储库版本更改（或者我仍然以某种间接方式依赖？）但必须手动获取所有源代码并对这些东西进行某种管理。
构建并使用自定义图像 只需构建并配置一次合适的服务器，获取其快照（作为虚拟机或其物理 HD iso 映像），然后在新物理服务器上扩展其映像或将虚拟机导入可视化主机即可。优点和缺点：当然不再有版本更改和依赖关系的麻烦，但它如何可靠？是的，如果我们谈论的是虚拟机，这是一件小事，但有时我们必须在物理机上部署项目，我们只能通过 SSH 访问。
如果只是小版本变更，则接受更新 不要太担心错误修复和版本更改，因为修复了关键安全问题会导致小版本号上升。尽快更新即可。优点和缺点：McAfee PCI Compliance 肯定会很高兴，我们的客户也会很高兴，但这不是很危险吗？如果我们没有覆盖默认 PHP 配置值的微小更改怎么办？这难道不是一场彻底的灾难吗？
亲爱的专家，有什么建议吗？
答案1
好的，让我们总结一下：
您面临的主要问题是您需要运行较新版本的 PHP/MySQL，但是当您的 QA 团队在新系统上测试软件时，该版本已经过时了。
这不是你们团队的失败；这是 QA 团队的失败。
您的 QA 团队应该有自动化测试用例。您的开发人员应该在开发过程中提供测试模块。例如：
- 开发商建立按比例计费系统
- 开发人员提供按比例计费的测试接口（即接受测试系统所需的所有详细信息，但实际上并不生成发票。或者可能生成，但在暂存系统中）。
- QA 团队设计了一系列测试来执行例行测试。输入是什么，结果是什么正确的结果如何？例如，每月 50 美元，按半个月计算 == 25 美元。
这最后一步应该完全自动化。确定任何错误应该需要几分钟或几小时（取决于软件的复杂性或有多少测试）。例如
- PHP 将浮点运算从正常舍入更改为向上舍入（始终向上舍入）
- 按半个月 5 美元/月按比例计费的测试用例
- 正确答案：2.50 美元，但测试用例返回 3 美元。自动失败。
现在，我知道这些都不能真正回答你的问题，所以如果你的 QA 团队无法解决，那么我们还有什么其他选择：
这个问题没有一个正确的答案。就我个人而言，我们对软件的处理方式是您的最后选择 - 我们接受所有更新和服务包到我们的运行时环境，但我们不会在没有彻底和完整的 QA 分析的情况下更改版本。尽管如此，我们在运行时中使用的软件（即 MSSQL 和另一个后端，而不是 PHP）每 18 个月到 2 年才发布一次新版本，中间有更新和服务包，因此在主要推出之间有足够的时间。
在我们的临时系统上进行 QA 测试后，我们将更新部署到我们的狗食系统首先。如果我们没有发现任何重大问题，我们会将运行时更新推广到我们的托管系统。如果我们仍然没有发现任何重大问题，我们会向我们的自托管客户发布通知，告知他们可以根据需要安装更新。
就我个人而言，每次收到预装的虚拟机时，我都会感到很尴尬。即使它是完全最新的（正如您所指出的，它们从来都不是最新的），我也需要努力将它集成到我们的网络中。有时它们附带的操作系统或运行时非常过时。
答案2
您的问题表述如下：
有时，您的服务器堆栈组件（包括 PHP 和 MySQL）中会发现严重的安全漏洞。
当发现此类缺陷时，PHP 和 MySQL 的开发人员会发布新版本。出于安全考虑，您使用的存储库中可能不再提供旧/不安全的版本。
您的 Web 应用程序必须符合 PCI 标准。如果您使用 PHP 和 MySQL 的旧版本且不安全，您的 Web 应用程序将无法通过 PCI 安全扫描，而 PCI 安全扫描必须通过才能达到合规性。
您永远无法使用修复了所有安全问题的当前版本，因为您的 QA 团队需要“花费大量时间”（似乎是几个月）才能批准使用 PHP 和 MySQL 的每个安全版本。事实上，他们等待批准安全更新的时间太长了，以至于您绝不已完全修补。
然后，您将继续探索各种可能性，以便更轻松地安装具有已知漏洞的旧版本的 PHP 和 MySQL。然而，上述第 1-3 项是不容商榷。
另一方面，第 4 项是可以协商。因此，你们公司的 QA 团队存在问题。将版本号增加 0.0.1（例如从 PHP v5.4.2 到 v5.4.3）的安全更新是非常不太可能破坏你的应用程序。
您应该在测试环境中安装新版本，运行自动化测试，进行最少的手动测试，然后开始使用。与任何更改一样，您需要制定一个后备计划以防出现意外问题，但是……拜托，您说的是已知漏洞的补丁！您承担的安全风险不是修补（顺便说一句，这包括保证 PCI 合规性扫描失败）远的超过您通过修补所承担的任何风险。
功能升级（例如从 PHP v5.3.x 升级到 v5.4.x）可能需要更彻底的测试，理由很充分：例如，5.4.0 删除了各种旧功能，一些旧应用程序可能需要相应更新。幸运的是，您实际上做需要几个月的时间来测试这些版本。这正是同时为当前版本和先前版本提供安全更新的原因。
这听起来很像您的 QA 团队将小安全更新与实际功能升级混淆了。
执行摘要：
- 安全不添加/删除功能的更新必须立即应用，并进行最少的测试。不可接受贵公司的流程可能会因官僚主义的拖延而导致小型安全更新，除非在初步测试中发现了实际问题。
- 到那个时刻特征发布更有可能破坏遗留应用程序，您的 QA 团队可以继续慢慢来。