jbx*_*jbx 5 php deployment software-distribution web-deployment composer-php
我已经开始使用Composer来创建一个新的PHP应用程序(它使用了一些框架和API,如Laravel,Smarty等),并且在开发过程中一切都很好.
但是,我不太确定如何在实时生产服务器上部署它.目录下各个模块的/vendor子目录似乎包含了许多我通常不会在应用程序中包含的内容(例如演示文件,安装自述文件,文档等).这是正常的,还是那些软件包的创建者对如何创建Composer包有错误的想法？
有没有一种标准的方法来创建一个干净的应用程序部署,只包含必要的分发文件,而不是其他与之无关的东西,甚至不应该存在(即使出于安全原因)？
我问的是最常用的工作流程,或者composer.json我应该考虑的特定命令或配置来实现这一点.
我提出的两个建议可以解决您的大部分担忧。
1）
使用composer update --no-dev 仅从锁定文件中删除任何开发依赖项。或者在composer.json 中调整您的要求以实现相同的目的。
理论上，包开发人员应该保持生产版本更干净（例如，不包括所有 phpunit 测试）。然而，是的，供应商库中存在大量“垃圾”是很正常的，主要是因为构建的概念在 PHP 中相对不常见，因此“源”和“目标”混合在一起。
演示和自述文件仍然是组件“分发”版本的必要部分，因此如果您指定 no-dev，它们仍然会存在，这只是说“我不是在开发这个包，我只是在使用它” 。
确实感觉缺少一个 Composer 功能：在此之上的一个级别确实是一个超级干净的部署缩小包。
2）
将您的供应商库保留在 Web 根目录之上。
这可以防止任何不必要的浏览供应商库，并消除站点访问者探索您的库的任何安全问题（如果这是您所担心的）。
例如我通常使用
domain
/api
/etc
/vendor
/www
/js
/css
/images
/index.php
/foo
/bar.php
www虚拟主机的 Web 根目录在哪里。所有入门级脚本都正常位于您的 Web 根目录中，并且自动加载的路径位于../vendor/autoload.php
或者，如果您在网站和 api 中使用 Laravel，那么 www/ 当然可以是 Laravel 根文件夹。
如果 Laravel API 是与“扁平”网站分开完成的，则 api 可以为您的 Laravel API 托管一个单独的虚拟主机。
（我在 Web 根目录之上保留其他文件夹，build用于SASS、JS、Grunt 等，可以安全地存储任何配置、密码、密钥等）。docssrcetc
3）
如果您仍然对包袱不满意，那么正如其他评论者所建议的那样，您需要查看一个可以清理问题的构建过程。但这可能会变得复杂并且难以维护！
例如，您可以构建到本地 www 部署文件夹（即，composer 更新，加上任何 grunt 任务、bower 安装、laravel/artisan 发布等），然后将其修剪回来（您必须设计的自定义脚本），并将其提交到代表已发布、扁平化部署目标的单独存储库。这就是您要部署到您的网站的内容。
这必须是自动化的，否则你会在第三次之后停止这样做:)
但是...您必须问为什么还要修剪供应商库。磁盘空间？它们没那么大。一般整洁吗？将文件夹视为黑匣子，只需阅读 API 文档即可。即不看:)
| 归档时间： |
|
| 查看次数： |
491 次 |
| 最近记录： |