`composer install`用于生产部署

Question

我们有一个关键任务应用程序，使用Chef

部署到~200个EC2实例

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

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

我们有另一个应用程序在每个部署上触发编译器安装，至少24小时我们无法部署，因为其中一个依赖项是＆＃34; down＆＃34;或感动。有什么方法可以绕过这个问题，同时仍然避免将我们的依赖项提交到我们的主要GIT中？

谢谢！

Answer 1

  

是否有任何技术可以“提高”作曲家安装的可靠性？

     

有什么方法可以绕过这个问题，同时仍然避免将我们的依赖项提交到我们的主要GIT中？

我的建议：

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

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

Answer 2

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

Answer 3

最佳做法非常简单。创建一个构建脚本以推送到带有版本标记的发行分支。

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

您使用的是什么软件包管理器，NPM，作曲家，凉亭等，都没有关系。遍历您的资源/资产清单并创建“已编译”（最小化/合并/等）版本很重要

相反，

NPM使用gulp和gulp任务解决了这一问题。鉴于作曲家是运行脚本...我也在搜索WordPress插件部署的过程，因为我们无权访问我们正在部署的生产服务器。