为什么我从不在生产中运行“ composer update”？ [英] Why should I never run 'composer update' in production?

问题描述

composer install 将在 composer.lock 文件中声明的任何时候安装，但 composer更新将更新所有依赖项，并根据<$ c中的要求创建一个新 composer.lock 文件$ c> composer.json 。

composer install will install whenever stated in the composer.lock file, but composer update will update all the dependencies and create a new composer.lock file based on what is required in composer.json.

如此之多的人说只在其中运行 composer update 发展。但是我的问题是做 composer更新是否替换了旧的 composer.lock 文件，如果您的应用程序要破坏它的话将中断，因为可能与新的更新依赖项冲突。

So many said only run composer update in development. But my question is doing composer update did replaced the old composer.lock file, if your app is going to break it will break, because there might be conflict with the new updated dependencies.

我遇到一种情况，我必须进行作曲家更新，该问题与 pcntl 扩展名。唯一的解决方案是进行 composer更新 PHP pcntl模块安装

I came across with a situation where I must do composer update, the issue is related to pcntl extension. The only solution is to do composer update PHP pcntl module installation

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

I don't understand why people are afraid of running composer update on production.

推荐答案

TLDR;

请勿运行生产中的Composer更新或 composer安装。在其他地方执行它，并将结果上传到生产环境。但是，如果您必须执行以下任一操作，请始终运行 install 并创建全新安装；永远不要更新。 安装更可预测且更可靠，使用 update ，您可以不受项目任何依赖的约束。

TLDR;

Do not run composer update nor composer install in production. Execute it somewhere else and upload the result to production. But if you HAVE to run either: always run install and create a fresh installation; and never update. install is more predictable and reliable, with update you are at the mercy of any of the project's dependencies.

Composer递归工作。因此，即使您在 composer.json 中有非常严格的版本限制，通过运行 composer update ，您也不会进行更新

Composer works recursively. So even if you have very tight version constraints in your composer.json, by running composer update you would be updating not only your dependencies, but your dependencies' dependencies.

虽然大部分时间，但这不会导致破坏，有时强>会。一个依赖关系可能会导致行为改变，从而可能以您未测试过的方式影响您的代码。

While most of the time this won't introduce breakage, sometimes it will. One dependency down the line may introduce a change of behaviour that may impact your code in a way you may have not tested against.

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

Also, it's basically using the wrong tool for the job. Composer is a dependency management tool, not a deployment tool. To deploy your code to production you should be using some sort of code deployment tool (even if that "tool" is as simple as an FTP upload and a couple of scripts).

适当的流程是：

• 执行所有要求和 update 在开发计算机上调用，您可以在其中无风险地测试项目。这将生成 composer.lock ，这是整个项目的已知状态，并且安装了离散的版本。



• 创建使用 install --no-dev 的新可安装版本。在这一步上，您还应该转储优化的自动加载器，运行安装后脚本等。我通常将其分为多个步骤：

• Do all the require and update calls on your development machine, where you can test the project without risk. This generates a composer.lock, which is a known state for the whole project, with discrete installed versions.

• Create a new installable version doing install --no-dev. On this step you also should dump an optimized autoloader, run after-install scripts, etc. I usually separate this in more than one step:

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

^^这是对所有内容的完整，静默安装，不包括开发依赖项。

^^ This for a complete, silent installation of everything, excluding development dependencies.

composer dump-autoload --optimize --no-dev

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

^^ To dump an optimized autoloader script suitable for production.

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

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

^^ This is mostly for Symfony, but if you have any post-install scripts to run (e.g. to copy assets to your "public" directory, warmp-up some type of cache, anything like that), this would be a good moment to do it.

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

The result of the above step should be tested (in what typically is a staging environment), and then pushed to production whole (your client code, the vendor folder, the configuration tailored for prod, etc); using whatever deployment method you prefer.

这篇关于为什么我从不在生产中运行“ composer update”？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！