`composer install` 用于生产部署答案

【问题标题】：`composer install` for production deployments`composer install` 用于生产部署
【发布时间】：2016-07-22 08:37:07
【问题描述】：

我们有一个关键任务应用程序，使用 Chef 部署到大约 200 个 EC2 实例

我们的供应商目录当前被 GIT 忽略，但我们已将重要的依赖项提交到其他地方的 GIT 并正在自动加载它们。我们的计划是迁移到更传统的方法，即通过 /vendor 中的 Composer 安装所有内容并使用 composer 自动加载器。

我的问题是： 当我们发布/批量部署（同时有 200 多台服务器）时，代码会从 GIT 拉到服务器上的新发布目录中，因此我们需要执行我们的作曲家安装。是否有任何技术可以“增加”作曲家安装的可靠性？或者实际上没有什么可担心的。鉴于我们的服务器数量，即使是 1% 的故障率也意味着客户端出现中断。

我们有另一个应用程序会在每次部署时触发 composer install，并且至少在 24 小时内我们无法部署，因为其中一个依赖项“关闭”或移动了。有哪些方法可以规避这个问题，同时仍然避免将我们的依赖项提交到我们的主 GIT 中？

谢谢！

【问题讨论】：

标签： git deployment composer-php

【解决方案1】：

最佳做法很简单。创建一个构建脚本以推送到带有版本标签的发布分支。

我知道我们在这里不是用 C 语言编译代码，但了解创建可用于生产的东西的步骤很重要。

无论您使用什么包管理器、NPM、composer、bower 等都无关紧要……重要的是要检查您的资源/资产清单并创建“已编译”（缩小/组合/等）版本.

相比之下，NPM 通过 gulp 和 gulp 任务解决了这个问题。而作曲家作为运行脚本......我也在寻找用于 WordPress 插件部署的流程，因为我们无法访问我们正在部署的生产服务器。

【讨论】：

【解决方案2】：

我们实现了 Jenkins 来克隆我们的 GIT，运行 composer install 进行生产，执行一些 shell 脚本来帮助打包，我们生成一个 .tar.gz 并将文件发布到 AWS S3 上的构建存储桶中（文件名基于正在构建的分支）。我们调整了我们的部署系统以从 S3 存储桶中获取（它具有非常有限的权限以保护对代码的访问）

【讨论】：

【解决方案3】：

是否有任何技术可以“提高”composer install 的可靠性？

有哪些方法可以规避这个问题，同时仍然避免将我们的依赖项提交到我们的主 GIT 中？

我的建议：

不要在生产环境中运行 Composer
构建和打包您的应用程序以进行部署
运行 composer install 并获取依赖项是一个构建步骤
构建工具链的最终产品是一个打包的应用程序，包括供应商依赖项和自动加载 - 准备好部署
然后将您的软件 v1.2.3 部署到 x 个实例

（旁注：Composer Autoloader 生成可重定位的文件。路径是动态的，不绑定到特定目录。这允许解压缩打包的应用程序，并获取供应商依赖项并将自动加载生成到任何文件夹中。）

【讨论】：

您好，感谢您的回复！考虑到我们的部署实际上是使用 Chef 的 GIT 克隆，您在哪里推荐“打包的生产构建”？在 GIT 中注册的代码库的“发布”分支代表“打包的生产构建”状态是否是错误的？还是应该将代码构建并存储在其他地方以供我们的实例远程使用？我倾向于说这个构建应该存在于我们的主要 GIT 存储库之外，以避免混淆/意外。有什么建议/工具可以促进这一点吗？
嘿！它不适用于git clone。 git checkout 包含composer.json（或者理想情况下是composer.lock）。基于此，依赖项被拉入。——当然，可以将它们存储回 Git 并基于“包含依赖项”分支创建发布标签，但我不建议这样做。
should the code be built and stored elsewhere for remote consumption by our instances? 是的，构建应该在外面。例如，您可以使用简单的 makefile（或 PHP 构建脚本或基于 Ant/Phing 的 build.xml 文件）来放置一些构建任务：composer install + zip + upload to downloads folder for releases。
或者，如果您使用 CI 服务，例如 Travis 或 Jenkins：当您将开发分支中的最新功能合并到 master.. 并将其标记为新发布版本时，CI 服务器会运行测试，然后构建任务和（如果是新标签）将所有内容打包并发布到，例如Github 发布或内部 FTP。