具有CI工作流程和单一功能部署的庞大TYPO3项目

Question

我们有一个由多个开发人员组成的庞大的TYPO3项目。 我们试图通过GIT，作曲家和Jenkins建立CI基础设施。 我们拥有开发（无用），过渡和生产环境。 登台服务器上同时具有多个功能是很常见的。 由于不同的人负责测试这些功能，因此通常不会同时将这些功能应用于生产服务器。 因此，我们设置了以下工作流程：

所有开发人员都从master分支开始，并创建它自己的功能分支。 当功能应转到登台服务器时，应推送功能分支。 我们有一个配置，其中定义了所有功能分支，应该转到登台。 Jenkins先生在构建项目之前合并了所有功能分支，并将所有内容部署到登台服务器。 成功测试一项功能并投入生产后，必须将功能分支合并到master。 詹金斯先生（Jenkins）负责构建该项目，并将一切部署到生产中。

到目前为止，我们对工作流程非常满意，除了以下几点：composer.lock文件。

功能可以更新或安装软件包。 一旦两个功能分支操纵了composer.lock文件，就会与该文件的“哈希”发生冲突，该冲突无法自动合并。

我认为没有干净的解决方案。 对我而言，唯一的解决方案是从存储库中排除composer.lock文件，并让Jenkins先生进行“作曲者更新”，这将导致所有必需软件包的状态不确定。 我认为最干净的方法是在测试完所有功能之后将整个开发环境合并到生产中，但这由于组织原因而无法实现。

这个工作流程是一个巨大的优势案例，还是有最佳实践解决方案？

谢谢你的帮助！

Answer 1

您确实应该将composer.lock文件添加到您的git项目中，因为否则您将在jenkins上获得不同的版本，当然，对于每个开发人员来说！

我合并的内容不会超过jenkins上的当前功能+母版，并且可以手动解决可能的合并问题

Answer 2

我的建议是：

• 仅将composer.lock保留在（功能）分支和（版本）标签上
• 分支是稳定的，并且用于开发新功能的版本上下文已锁定
• 从主要开发分支（主机）中删除composer.lock
• 母版始终在边缘发展，直到功能（或功能集）冻结为止
• 将功能分支合并到开发分支时，将composer.lock文件排除在外
  • 您可以使用git merge --no-commit ，然后编辑合并，取消stage composer.lock，然后使用git commit -m "merged <feature-branch>"
• 在功能冻结时，分支出（新版本标签）并添加composer.lock以锁定版本上下文

归结为： feature branch (locked) ⇾dev dev-master (unlocked) ⇾ version tag (locked) 。

---

• 从（锁定）版本标记构建部署程序包+分发（发布）
• 在生产环境中安装/升级发布包，或遵循在生产环境中使用composer的方法并安装版本标签:(

我认为，最干净的方法是在测试完所有功能之后将整个开发环境合并到生产环境中。

合并到生产中:)-错误，那太容易了！