我知道很多人对频繁的版本变化并不满意。 特别是当你坚持使用的最新版本的PHP或MySQL不再在你的仓库中可用时（在我的情况下是REMI），但是你必须安装一个新的服务器，其中包含一些版本稍低的PHP / MySQL包旧的/较早的）从存储库中可用的。
大多数情况下，我们在Centos 5.8 GNU / Linux x86_64操作系统上使用最新版本的Apache，PHP，MySQL。
但是现在，我们的QA团队需要花费很多时间来testing我们所有的项目，以便与新版本兼容，速度如此之快，以至于我们在QA团队的绿灯下更新PHP和/或MySQL和/或安装一个具有特定版本的新服务器，我们发现它已经过时，现在它被更新的版本所取代。
当McAfee PCI Compliance说我们的站点使用潜在危险的PHP版本并迫使我们用新版本的PHP升级所有的服务器时，尤其如此。
目前，我们的默认工作环境包括：
OS：
CentOS版本5.8（最终版）Linux censored.example.com 2.6.18-308.4.1.el5＃1 SMP Tue Apr 17 17:08:00 EDT 2012 x86_64 x86_64 x86_64 GNU / Linux
阿帕奇：
服务器版本：Apache / 2.2.3服务器内置：Feb 23 2012 21:16:56
PHP：
PHP 5.3.13（cli）（构build于：May 9 2012 16:20:57）版权所有（c）1997-2012 PHP集团Zend引擎v2.3.0，版权所有（c）1998-2012 Zend技术与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编译器和依赖关系的好日子。 优点和缺点：不再依赖版本库版本的改变（或者仍然以某种间接的方式进行），但是必须手动获取所有的源代码，并对其进行某种pipe理。
构build和使用自定义映像只需构build和configuration适当的服务器，将其快照（作为虚拟机或其物理HD iso映像），而不仅仅是在新的物理服务器上展开映像或将虚拟机导入可视化主机。 优点和缺点：版本更改和相关性肯定不会让人头痛，但它的可靠性如何？ 是的，如果我们正在讨论虚拟机，那么这是一个和平的蛋糕，但是有时候我们不得不在一台物理机器上部署项目，而我们只有SSH访问权限。
接受更新，如果它只是次要版本更改不要担心错误修复和版本更改由于重要的安全问题修复，上升次要数量。 只是尽快更新到他们。 优点和缺点：McAfee PCI Compliance当然会很高兴，对我们的客户也会这样做，但这不是危险的吗？ 如果这是对我们未被覆盖的默认PHPconfiguration值的微小改变呢？ 这难道不是一场可能的灾难？
任何build议亲爱的专家？
好吧 – 让我们来解释一下：
您面临的主要问题是您需要运行更新版本的PHP / MySQL，但是当您的QA团队在新系统上testing了该软件时，该版本已过时。
这不是你的团队的失败; 这是质量保证小组的失败。
你的QA团队应该有自动化的testing用例。 你的开发者应该随时提供testing模块。 例如：
这最后一步应该是完全自动的。 它应该花几分钟或几小时（取决于软件的复杂性或多lesstesting）来确定任何错误。 例如
现在，我知道这些都不能解决您的问题，所以如果您的QA团队无法修复，那么我们还有其他select：
没有一个正确的答案。 就我个人而言，我们用软件做的是最后一个select – 我们接受所有更新的服务包和运行时环境，但是我们不会在没有彻底和完整的质量保证分析的情况下更改版本。 尽pipe我们在运行时（即MSSQL和另一个后端，而不是PHP）中使用的软件仅每18个月到2年发布一个新版本，其中包含更新和服务包，因此在主要部署之间有足够的时间。
在对分期系统进行质量保证testing后，我们首先将更新部署到我们的dogfood系统 。 如果我们没有发现任何重大问题，我们会将运行时更新展示给我们的托pipe系统。 如果我们仍然没有任何重大问题，我们会发布通知给我们自己托pipe的客户，他们可以根据需要安装更新。
就我个人而言，每次我收到一个预先打包的虚拟机时，都会畏缩。 即使它完全是最新的（他们从来都不是，正如你所指出的那样），那么我需要把它融入到我们的networking中去。 有时候，他们会运行可怕的过时的操作系统或运行时间。
你已经说过你的问题如下：
定期在服务器堆栈的组件中发现严重的安全漏洞，包括PHP和MySQL。
当发现这些缺陷时，PHP和MySQL的开发者发布新版本。 为了安全起见，旧版本/不安全版本可能不再在您使用的版本库中可用。
您的Web应用程序必须符合PCI标准。 当您使用旧的，不安全的PHP和MySQL版本时，您的Web应用程序将无法通过必须通过的PCI安全扫描来达到合规性。
由于您的QA团队需要花费大量时间（显然是几个月）来使用PHP和MySQL的每个安全版本，所以您永远无法使用当前版本的所有安全修复程序。 事实上，他们等待这么久才能批准安全更新，以至于您从未完全打补丁。
然后，继续探索使安装具有已知漏洞的旧版本PHP和MySQL变得更加容易的各种可能性。 但是， 以上第1-3项不可商量 。
另一方面，项目4 是可商议的。 Ergo， 贵公司的QA团队是问题所在。 将版本号增加0.0.1（例如从PHP v5.4.2到v5.4.3）的安全更新不太可能破坏您的应用程序。
您应该在testing环境中安装新版本，运行自动化testing，进行最less量的手动testing，然后进行滚动。 就像任何变化一样，如果出现意想不到的问题，您需要制定一个退出计划，但是……来吧，您正在讨论已知漏洞的补丁！ 您通过不修补（顺便说一句，包括保证PCI符合性扫描失败）所带来的安全风险远远超过了修补所带来的风险。
function升级（例如从PHP v5.3.x到v5.4.x）可能需要进行更彻底的testing，出于很好的理由：例如，5.4.0删除了各种旧function，并且可能需要更新一些旧应用程序。 幸运的是，您确实需要几个月来testing这些版本。 这就是为什么同时为当前版本和以前版本提供安全更新的原因。
这听起来像是你的QA团队非常担心小安全更新和实际function升级。
执行摘要：