php - 将 50 多个安装升级到 PHP 5.3

Question

作为网页设计师，我们在 2011 年过得很好，有超过 50 个（不同的）cms 和其他 php 5.2 驱动的应用程序。有些还对核心进行了自定义。有人如何将如此数量的应用程序升级到 php 5.3？

php 的开发者有没有想过这个问题？许多（流行的）功能只是贬值了，给像我们这样的人带来了很多工作。

我真的不知道如何最好地进行

score 11 · Accepted Answer

简短的回答

这取决于。

迁移策略将受到源本身的质量和内容以及架构和工作流程的影响。没有“灵丹妙药”可以让它发挥作用。

更长的答案

应该怎么做

您会自动升级所有临时站点，运行所有单元测试，如果它们都通过，则运行验收测试。修复出现的问题，直到您通过所有测试。然后让您的 QA 人员确保一切都 100% 正常。整个过程主要由您的持续集成系统/框架运行。

当所有工作都在暂存环境中运行时，您关闭每个站点进行维护，将更新的代码部署到生产环境，升级服务器的软件，然后恢复站点。

你将如何（很可能）必须这样做

由于您的软件都没有任何单元/验收测试，没有最新的规范，甚至没有持续集成系统的概念，您将不得不以艰难的方式去做：

'step 1' take a survey of different servers setups on which your projects 
         are deployed (if you have all project on single box with 
         virtual-hosts, you can skip this bit )
'step 2' find somewhere a computer, which can temporary act as local server
<foreach setup>

    'step 3' install/configure this temporary server to be exactly like 
             the "setup"
    <foreach project on that setup>

        'step 4' BACKUP ALL THE STUFF
        'step 5' copy the latest source and DB from the production server
        'step 6' upgrade the software
        'step 7' see what has *blown* up and fix what you can find    
        'step 8' pass to the QA team 
        'step 9' store the source

    </endforeach project>
    'step 10' take the server with this configuration down for maintenance
    'step 11' upgrade software on the server
    'step 12' deploy all the projects from this server 
    'step 13' prayer (optional)

<endforeach setup>

这是有点“简短”的版本。基本上你必须逐个服务器，在本地克隆它，然后升级，修补项目。然后升级每台服务器并安装补丁版本。和希望。

你应该升级吗？

_{客户不会为此付费。}

由于您有大约 50 个不同的项目，您将不得不调查它是否值得花费时间和金钱。经过这样的分析，您可能会发现将大多数项目标记为“遗留”并将服务器升级到最新的 5.2.x对企业来说更有意义。然后别管它。

当然，即使您决定不升级大多数项目，也会有一些项目需要升级。特别是具有持续合同的项目，可为公司带来稳定的收入来源。

我建议开始升级那些摇钱树项目，因为无论如何你都必须这样做。然后根据这种经验，您可以计算其余“投资组合”的成本。

下次呢？

PHP 5.4 已经发布（在上次编辑时，5.5 已经发布）。大多数公司到今年年底都会面临一个问题：“是时候开始使用 5.4 了吗？” . 有的早一点，有的晚一点。您使用的框架和 CMS 也有更新的趋势。

底线：您的公司整体应该开始研究简化此流程的方法。

那么当你升级到 PHP 5.5 并且mysql_*函数开始显示E_DEPRECATE警告时呢？请参阅文档中的红框mysql_affected_rows()。这不是一次性的事情。

投资实施更好的部署策略（涉及单元测试和持续集成）可能是明智的。

_<rant>

_{php 的开发者有没有想过这个问题？许多（流行的）功能只是贬值了，给像我们这样的人带来了很多工作。}

_{已弃用的功能和功能已在文档中标记为多年。例如，ereg()不应该使用引用传递对象的通知，自从我开始学习 PHP 以来就一直存在。弃用警告将主要影响 PHP4 代码库（在这种情况下，您的问题有点虚伪）。}

_{我看不出社区多年来接受的强制做法是如何“导致大量工作”的。}

_</rant>

score 3 · Accepted Answer

首先，将程序存储在通过包管理系统（yum、apt-get 等）安装的包（RPM、DEB 等）中，并正确设置依赖信息。

然后通过一个适当的发布链和一个集成步骤来测试升级依赖项时代码是否中断。诸如 Jenkins 之类的 CI 服务器可以运行您的自动化测试并为您构建包。

如果有问题，它们会很快出现，您可以着手修复它们。使用您通常的内部流程来确定优先级和修复错误（请注意，值得关注的是在给定包中作为一个批次的依赖升级引入的所有错误，而不是通过并行处理十几个程序来分散工作）。

score 3 · Accepted Answer

显然，您应该遵循建议的升级做法；其他答案正在提供它们。

有流程和程序步骤要采取；我没有具体的建议，事实上tereško的回答非常好恕我直言

但是如果代码库本身必须更改，您可以选择：

您可以手动完成所有操作（这似乎是隐含的假设）。这不是令人惊讶的建议。
您可能能够自动应用更改。

纯手动方法要求您发现所有类型的不兼容性（语言更改、框架更改、基础架构替换……），弄清楚如何普遍修复它们，然后在适当的情况下应用每种修复类型。最后一部分真的很昂贵，因为它需要你检查每一行代码，如果有问题就修复它。

自动更改无助于发现问题或解决方案的一般工作。但是一旦你弄清楚如何解决问题，它可能有助于在所有必要的地方应用该解决方案。

每个问题需要的是一种“如果你在代码中看到这个，就把它改成那个”。这种非正式的想法可以打包为程序转换，用于修改代码的正式规则。

我的公司提供了一个工具，即DMS Software Reengineering Toolkit，它是一个程序转换引擎。它可以使用特定语言的前端分析和转换多种计算机源代码；它有一个适合此任务的PHP 前端（解析器/prettyprinter）。DMS 就是为此类任务而设计的，这就是为什么它的部分名称是“软件再造工具包”。我们已经将它用于更棘手的再造任务。

所以想法是将所需的更改打包为程序转换，并使用像 DMS 这样的工具来应用它们。编写修复代码中问题的规则将是一项艰巨的任务，但一旦完成，DMS 就可以可靠地应用这些规则。因此，您投资于前几个系统（以调整和验证规则）以使更新最后 48 奇数有效。

这不是灵丹妙药。你不能总是很容易地为你想要的东西写一个转换。但是，当您要进行大量更改并且希望在整个代码中进行更改时，使用工具尽可能多地可靠地完成比手动完成所有事情要好得多。

score 2 · Accepted Answer

我想这个列表： http: //php.net/manual/en/migration53.incompatible.php是您所需要担心的。

score 2 · Accepted Answer

2

最好的方法是遵循PHP 5.3 迁移指南（然后是PHP 5.4）。

于 2012-05-10T16:34:30.207 回答

score 0 · Accepted Answer

如果您正在使用像 cherokee 这样的替代 Web 服务器，您可以使用 PHP 的并行安装。如果由于操作系统中的安装限制而无法这样做，您可以随时使用 chrooted 环境并更改 php 解释器的端口。

如果我必须更新 php 版本，我会在页面中添加第二个域，例如使用新 php 版本的 updated.domain.com。普通用户看不出区别。但不幸的是，这只有在您使用相对路径并且文件中没有硬编码域时才有效。