为什么我不应该在生产中运行“composer update”？

Question

作曲家安装将在composer.lock文件中说明的任何时候安装，但是作曲家更新将更新所有的依赖关系，并根据是什么创建一个新的composer.lock文件需要在composer.json。

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

我遇到了一种情况，我必须执行composer更新，这个问题与pcntl扩展有关。唯一的解决方案是进行composer更新PHP-pcntl模块安装

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

Answer 1

我的想法如下：

你不应该在没有参数的情况下使用作曲家更新。

composer update读取composer上列出的每个包。json，并将其更新为与指定版本约束兼容的最新可用版本。

在一个完美的世界里，所有的图书馆都将正确地遵循Semver，它不应该有任何副作用。但是从技术上讲，这并不总是正确的，你可以下载一个与前一个版本不兼容的版本，或者只是一个有未更正错误的版本。

所以，一次更新你所有的包可能会导致一些问题，除非你有时间检查你网站上的所有东西，以确保没有出错。

但是，当然，您有时必须更新特定的包，因此使用composer update xxx/xxx非常有用，前提是您要检查包的所有实现。

当更新的软件包经过全面测试后，您可以将代码提交到登台/生产，然后运行composer安装，以确保在所有平台上都有相同版本的软件包和依赖项。

长话短说，以下是我使用的流程：

• composer要求xxx/xxx安装新软件包
• composer update xxx/xxx更新特定软件包
• composer在安装软件包时在所有环境上安装。锁定文件已更新

其他想法

我曾经偶然发现一个实现，它可以在composer.json.中给出包的确切版本。开发人员解释说，这样你就可以在没有损坏的情况下使用作曲家更新。

我不同意这个选项，因为即使使用composer中的确切版本。json，依赖项是不固定的，编写器更新可能会导致其中的潜在错误。

Answer 2

我的想法是，

• 系统的当前工作状态非常重要，因为我假设已经对它进行了一些测试。
• 执行作曲家更新意味着，作为应用程序一部分的库会有更新，这可能会导致系统崩溃。因为它们是依赖于依赖于图书馆的图书馆。
• 最后，如果需要作曲家-更新，我宁愿这样做：
  • 签出一个开发环境和作曲家更新，
  • 确保应用程序在开发环境上进行了彻底测试
  • 然后安装在live/生产与作曲家安装

Answer 3

请勿在生产中运行composer update或composer install。在其他地方执行，并将结果上载到生产服务器，但不要上载到承载应用程序的同一目录。作为一般规则，您不应该在服务的同时修改正在服务的应用程序。创建应用程序的另一个副本，当它准备好时，用最接近即时的命令替换它（例如mv或ln-s）。

但是如果你必须运行其中任何一个：总是运行安装并创建一个新的安装；永远不要更新。项目的依赖关系。

作曲家递归工作。因此，即使您的composer.json中有非常严格的版本约束，通过运行作曲家更新，您不仅要更新依赖项，还要更新依赖项的依赖项。

虽然大多数情况下这不会导致破损，但有时会。一个依赖关系可能会导致行为的改变，这可能会以您没有测试过的方式影响您的代码。

此外，它基本上使用了错误的工作工具。Composer是一个依赖管理工具，而不是部署工具。要将代码部署到生产环境，您应该使用某种代码html" target="_blank">部署工具（即使该工具像FTP上传和几个脚本一样简单）。

适当的流程是：

• 在您的开发机器上执行所有的要求和更新调用，在那里您可以无风险地测试项目。这将生成一个composer.lock，这是整个项目的已知状态，具有离散的安装版本。
• 创建一个新的可安装版本，执行安装--no-dev。在这一步中，您还应该转储优化的自动加载程序，运行安装后脚本等。我通常将此分开不止一步：

>

composer安装--首选dist--无脚本--无进度--无建议--无交互--无开发：

^^这是一个完整的静默安装，不包括开发依赖项。

composer转储自动加载--优化--无开发

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

composer运行脚本--无dev-post-install cmd

^^这主要是针对Symfony的，但如果您有任何安装后脚本要运行（例如，将资产复制到“公共”目录，预热某种类型的缓存，诸如此类），这将是一个很好的时机。

• 应测试上述步骤的结果（通常是在暂存环境中），然后将其推送到整个生产环境（客户机代码、供应商文件夹、为产品定制的配置等）；使用您喜欢的任何部署方法

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