TYPO3 + Composer +部署

Question

我想，在将项目迁移到composer时，一个很大的好处是保留了一个小的项目存储库，可以将编写器管理的东西(TYPO3源代码+公共扩展)排除在VCS之外。在部署时，在活动系统上的“composer安装”总是会导致期望的状态，而不会有风险。

但是官方的TYPO3文档说：

你不应该在你的网站上运行作曲家。您应该始终在本地或专用部署机器上运行composer，这样就可以测试一切是否正常。运行测试之后，可以将供应商和公用文件夹部署到web服务器上。

我听不懂为什么。因为这导致每个项目存储库都需要在projects中包含整个TYPO3源，尽管它们可能被排除在其中。采取这种方法的原因是什么？“我的”方法的风险是什么？

编辑:当然，我要指定确切的版本号，直到编写程序包的修订级别。这样做，我的做法是否仍有风险？

Answer 1

composer可以以多种方式使用，我也想知道为什么TYPO3文档在这里显示出如此强烈的观点(没有理由)。

它提到了这一模式：

• 带有composer的本地开发系统，用于更改composer.json/composer.lock
• 构建环境/CD管道运行composer install --no-dev，只将现成的文件系统复制到暂存/活动系统。
• 没有composer的活动服务器与用户数据集成(数据库和/fileadmin)

这是一些人(包括我)喜欢的，因为它有助于在可复制(构建)环境中的测试步骤。如果构建步骤包含比composer更多的内容(例如，资产构建)，它也能很好地工作。

虽然只有对composer来说，如果它必须安装在live (+它的依赖项)上就不会有太大的区别，但是构建步骤越多，您就必须安装更多的“开发”软件。这可能就是一些人划定界限的地方，他们认为开发->构建-> live是一个更加强大的模型。

虽然构建环境很可能位于活动服务器上，但我不希望它处于已发布的状态(我不知道您是否引用了该状态)。因此，我至少要做一些复制(或者更确切地说是符号链接切换)，以确保构建/测试过程中的问题不会影响发布的站点。

其他模特也能用。

Answer 2

当您使用composer通过TYPO3获取composer install环境的源时，您就不知道您将得到哪个TYPO3扩展的确切版本。composer.json文件定义了允许的版本号范围，而不是确切的版本号。当您有一个本地或部署环境时，那么composer安装将在版本1中给出一个状态扩展1，在版本2中给出扩展2，然后测试所有内容。两周后，你决定一切都好。但是，如果在运行系统2周后使用composer，那么扩展1可能会出现在版本2中，其中有一个严重的错误。然后，一个作曲家的运行会给你带来这个错误版本2的扩展1，这不是你想要的。

解决办法是存在的。

如何使用Composer安装特定版本的软件包？