php - 为什么我不应该在生产环境中运行 'composer update'？

Question

composer install 将在 composer.lock 文件中指定时安装，但 composer update 将更新所有依赖项并创建一个 新 composer.lock 文件基于composer.json 中的要求。

很多人说在开发中只运行composer update。但我的问题是 composer update 确实替换了旧的 composer.lock 文件，如果你的应用程序要中断它就会中断，因为可能与新的更新发生冲突依赖项。

我遇到了必须执行 composer update 的情况，这个问题与 pcntl 扩展有关。唯一的解决方案是执行 composer update PHP pcntl module installation

我不明白为什么人们害怕在生产环境中运行 composer update。

Answer 1

TLDR;

不要在生产环境中运行composer update 或composer install。在其他地方执行并将结果上传到生产服务器，但不要上传到托管应用程序的同一目录。作为一般规则，您不应在正在提供服务时修改正在提供服务的应用程序。创建应用程序的不同副本，当它准备就绪时，将其替换为最接近即时的命令(例如 mv 或 ln -s)。

但是，如果您必须运行其中之一:始终运行 install 并创建全新安装；永远不要更新。 install 更具可预测性和可靠性，使用 update，您将受到任何项目依赖项的支配。

---

Composer 以递归方式工作。因此，即使您的 composer.json 中有非常严格的版本限制，通过运行 composer update，您不仅会更新您的依赖项，还会更新您的依赖项的依赖项。

虽然大部分时间这不会导致破损，但有时会。一个依赖关系可能会引入一种行为变化，这种变化可能会以一种您可能没有测试过的方式影响您的代码。

此外，这基本上是使用了错误的工具来完成工作。 Composer 是一个依赖管理工具，而不是部署工具。要将代码部署到生产环境中，您应该使用某种代码部署工具(即使该“工具”就像 FTP 上传和几个脚本一样简单)。

适当的流程是:

• 在您的开发机器上执行所有 require 和 update 调用，您可以在其中无风险地测试项目。这会生成一个 composer.lock，这是整个项目的已知状态，具有离散的安装版本。
• 通过install --no-dev 创建一个新的 可安装版本。在此步骤中，您还应该转储优化的自动加载器、运行安装后脚本等。我通常将其分为多个步骤:

1. composer install --prefer-dist --no-scripts --no-progress --no-suggest --no-interaction --no-dev:

   ^^ 这用于完整、静默安装所有内容，不包括开发依赖项。

2. composer dump-autoload --optimize --no-dev

   ^^ 转储适合生产的优化自动加载器脚本。

3. composer run-script --no-dev post-install-cmd

   ^^ 这主要用于 Symfony，但如果您有任何安装后脚本要运行(例如，将 Assets 复制到您的“公共(public)”目录，预热某种​​类型的缓存，诸如此类)，这将是做这件事的好时机。

• 应对上述步骤的结果进行测试(通常在暂存环境中)，然后将其整体推送到生产环境(您的客户端代码、供应商文件夹、为生产环境量身定制的配置等)；使用您喜欢的任何部署方法。

请注意，如果您使用任何“慢速”推送方法(FTP、复制、rsync 等)，您不应直接写入应用程序文件系统，而应创建应用程序的全新副本文件传输准备就绪后，使用快速方法将“生产”替换为新版本。一种流行且有效的方法是使用符号链接(symbolic link)作为“生产”根，因此您只需在上述所有内容完成并准备就绪后更新符号链接(symbolic link)，而不会影响正在运行的应用程序(否则可能由于突然包含属于不同版本的应用程序的文件而暂时损坏)。