使用Composer的开发/生产交换机时如何正确部署？

Composer可以选择仅在开发过程中加载多个依赖项，因此这些工具将不会安装在生产环境中（在实时服务器上）。从理论上讲，这对于仅在开发中有意义的脚本非常方便，例如测试，伪数据工具，调试器等。

可行的方法是require-dev使用开发中所需的工具添加一个附加块：

"require-dev": {
    "codeception/codeception": "1.6.0.3"
}

然后（理论上）通过

composer install --dev

问题与疑问：

Composer改变了行为，install并update在2013年发生了巨大变化，require-dev-dependencies现在已默认安装（！），可以随意创建一个带require-dev块的composer.json 并执行一个composer install重现。

作为最流行的部署方式，是推动作曲家。锁定（保存您当前的作曲家设置），然后composer install在生产服务器上执行，这也会安装开发资料。

在不安装-dev依赖项的情况下进行部署的正确方法是什么？

_{注意：我正在尝试在此处创建规范的Q / A，以阐明怪异的Composer部署。随时编辑此问题。}

为什么

恕我直言，有充分的理由说明为什么Composer将--dev默认使用该标志（在安装和更新时）。Composer通常在所需行为的方案中运行：

基本的Composer工作流程如下：

• 开始一个新项目：composer.phar install --dev，json和锁定文件已提交到VCS。
• 其他开发人员开始从事该项目：VCS和的签出composer.phar install --dev。
• 开发人员添加依赖项：composer.phar require <package>，添加--dev如果要在require-dev部分中提交包（并提交）。
• 其他人也可以：（结帐和） composer.phar install --dev。
• 开发人员需要较新版本的依赖项： composer.phar update --dev <package>和提交）。
• 其他人也可以：（结帐和） composer.phar install --dev。
• 项目已部署： composer.phar install --no-dev

如您所见 --dev标志的使用（远）次数比--no-dev尤其是，尤其是当从事该项目的开发人员数量增加时。

生产部署

在不安装“ dev”依赖项的情况下进行部署的正确方法是什么？

好，composer.jsonand composer.lock文件应该提交给VCS。不要忽略composer.lock它，因为它包含有关应使用的程序包版本的重要信息。

执行生产部署时，可以将--no-dev标志传递给Composer：

composer.phar install --no-dev

该composer.lock文件可能包含有关dev软件包的信息。没关系 该--no-dev标志将确保未安装这些dev软件包。

当我说“生产部署”时，是指旨在用于生产中的部署。我不是在争论一个composer.phar install应该在生产服务器上或可以在此进行审查的登台服务器上完成。那不是这个答案的范围。我只是指出如何composer.phar install不安装“ dev”依赖项的情况下进行操作。

题外话

该--optimize-autoloader标志在生产中也可能是理想的（它会生成一个类映射，这将加速应用程序中的自动加载）：

composer.phar install --no-dev --optimize-autoloader

或在完成自动部署后：

composer.phar install --no-ansi --no-dev --no-interaction --no-plugins --no-progress --no-scripts --no-suggest --optimize-autoloader

如果你的代码库支持的话，你可以换出--optimize-autoloader了--classmap-authoritative。更多信息在这里

实际上，我强烈建议AGAINST在生产服务器上安装依赖项。

我的建议是在部署机器上签出代码，根据需要安装依赖项（如果代码投入生产，则不包括安装开发依赖项），然后将所有文件移至目标计算机。

为什么？

• 在共享主机上，您可能无法进入命令行
• 即使您这样做，PHP可能仍在命令，内存或网络访问方面受到限制
• 可能未安装存储库CLI工具（Git，Svn），如果您的锁定文件记录了签出某个提交而不是以ZIP形式下载该提交（您使用--prefer-source或Composer已将其提交）的依赖项，则失败没有其他方法可以获取该版本）
• 如果您的生产机器更像是一台小型测试服务器（例如Amazon EC2微型实例），则可能甚至没有安装足够的内存来执行 composer install
• 虽然composer尝试不间断运行，但您对以部分中断的生产网站结尾感到如何，因为在Composers安装阶段无法加载某些随机依赖项

长话短说：在您可以控制的环境中使用Composer。您的开发机器确实合格，因为您已经拥有操作Composer所需的所有东西。

在不安装-dev依赖项的情况下进行部署的正确方法是什么？

使用的命令是

composer install --no-dev

这将在任何环境中都有效，无论是生产服务器本身，还是部署机器，或者是应该进行最后检查以发现是否有任何开发需求未正确用于实际软件的开发机器。

该命令将不会安装或主动卸载composer.lock文件中声明的开发要求。

如果您不介意在生产服务器上部署开发软件组件，则运行composer install将完成相同的工作，但只是增加了移动的字节数，并创建了更大的自动加载器声明。

现在require-dev默认情况下启用了Now ，对于本地开发，您可以执行composer install而composer update无需--dev选择。

要部署到生产环境时，需要确保composer.lock没有来自的任何软件包require-dev。

你可以用

composer update --no-dev

在本地进行测试后，--no-dev您可以将所有内容部署到生产环境并根据进行安装composer.lock。您在--no-dev这里再次需要该选项，否则作曲家将说“锁定文件不包含require-dev信息”。

composer install --no-dev

注意：小心任何可能在开发和生产之间造成差异的事物！我通常尝试尽可能地避免require-dev，因为包括dev工具并不是很大的开销。

在生产服务器上，我重命名vendor为vendor-<datetime>，并且在部署期间将有两个供应商目录。

HTTP cookie使我的系统选择新的供应商 autoload.php，并且在测试之后，我在它们之间进行了完全原子/即时切换，以禁用所有将来请求的旧供应商目录，然后几天后删除了先前的目录。

这样可以避免由我在apache / php中使用的文件系统缓存引起的任何问题，并且还允许任何活动的PHP代码继续使用以前的供应商目录。

尽管有其他答案建议反对，但我还是亲自跑步 composer install在服务器上，因为它比暂存区域（笔记本电脑上的VM）中的rsync快。

我用--no-dev --no-scripts --optimize-autoloader。您应该阅读每个文档，以检查这是否适合您的环境。

我认为最好将流程自动化：

在您的git仓库中添加composer.lock文件，确保在发布时使用composer.phar install --no-dev，但是在您的dev机器中，您可以使用任何composer命令而无需担心，这将不会投入生产，生产将其依赖项基于锁定文件。

在服务器上，您签出该特定版本或标签，并在替换应用程序之前运行所有测试，如果通过测试，则可以继续进行部署。

如果测试依赖于dev依赖项，因为composer没有测试范围的依赖关系，则可以使用dev依赖项（composer.phar install）运行测试，这不是一个非常好的解决方案，删除供应商库，运行composer.phar install- -无开发，它将使用缓存的依赖项，因此速度更快。但是，如果您知道其他构建工具中范围的概念，那将是一个hack。

自动化它，忘记其余的，去喝啤酒:-)

PS .：和@Sven注释一样，不要检出composer.lock文件不是一个好主意，因为这会使composer安装作为composer更新工作。

您可以使用http://deployer.org/实现自动化，这是一个简单的工具。