39

一段时间以来，我们一直在使用 Subversion 提交作为管道触发器进行持续集成和持续交付。最近，我们开始在一些带有git-flow的项目中使用 git ，我们正在尝试决定应该使用 git-flow 的哪个分支来触发持续集成和持续交付管道。

这里有两种方法：

1.使用开发分支

问题：使用 git-flow 我们应该在生产中部署发布（或主）分支，所以我们必须构建两个不同的管道，一个用于持续集成（分支开发），一个用于持续交付（分支主）。这可能会在生产中引入错误，因为生产中的版本与其他环境（集成、测试、暂存）中的版本不同。

2.使用主分支：

问题：这样一来，我们就不会有真正的持续集成，因为对这些分支的更改不是很频繁地推送。

哪个是管道中使用的正确分支？

4

3 回答 3

20

根据定义，Git-flow 和持续集成是不兼容的。分支是一种延迟集成的机制：当您提交到除 master（或trunk，如果您来自 Subversion）以外的分支时，您正在避免持续集成。进行持续集成很简单，但并不容易。

于 2016-07-23T05:32:53.423 回答
11

真相介于两者之间。如果你想在严格的 CD 管道中采用 git-flow，你应该为你的 CI 使用 release-branch：

  1. 对于每（一批）开发分支提交，让您的 CI 服务器自动创建一个发布分支并在其上运行所有测试。
  2. 如果失败，让它报告和/或删除分支，否则将其合并到 master。

基本思想来自 John Ferguson Smart 关于 Java Maven 项目中 CI/CD 的幻灯片（BDD in Action, Jenkins Definite Guide）。

于 2015-11-09T22:53:19.337 回答
8

在我看来，如果你想在持续交付中应用 git-flow，你应该有两个不同的管道，就像你在第一种方法中所说的那样。

我建议这种方法：

1.开发分支

  • 开发分支将触发提交构建：一旦将功能添加到开发分支（合并或拉取请求），CI 将构建、测试（单元测试和代码修订）并打包解决方案（使用“-develop- vX”后缀）。因此，团队能够在失败的情况下快速做出反应。
  • 一旦 Commit Build 成功完成，任务就完成了（否则，更改将被还原，提交更改的开发人员必须立即修复它）。与此同时，验收测试阶段开始将先前的构建部署到开发环境中，以执行验收测试套件（例如功能和回归测试），而不会阻碍开发人员的工作。完成后，将开发分支状态传达给团队。因此，团队意识到解决方案在当前 Sprint 期间的稳定性：如果验收测试阶段成功完成，则产品已准备好与 Master 分支合并（否则将被修复）。

2.主分支

  • 一旦 Sprint 完成，稳定的 Developer 分支（它是稳定的）将被合并并标记到 Master 分支。因此，主分支将触发主干提交构建，该构建将构建解决方案、测试它并打包以进行部署（该包现在与发布候选或主后缀一起存储）。
  • 如果主干提交构建成功完成（它应该可以工作），验收测试阶段将针对集成环境部署和验证验收测试。如果成功，新版本就可以投入生产了。否则，如果在 Commit Build 或 Acceptance Test Stage 出现错误，合并将被恢复。
于 2016-05-10T11:39:56.210 回答