使用git-flow持续集成和持续交付

Question

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

这有两种方法：

1.使用开发分支

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

2.使用主分支 ：

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

哪个是在管道中使用的rigth分支？

Answer 1

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

Answer 2

事实就在于两者之间。 如果要在严格的CD管道中采用git-flow，则应该为CI使用release-branch：

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

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

Answer 3

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

我建议这种方法：

1.发展分支

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

2.主分公司

• Sprint完成后，稳定的Developer分支（稳定）将合并并标记为Master Branch。 因此，Master Branch将触发Trunk Commit Build，它将构建解决方案，测试它并打包以进行部署（该软件包现在存储有候选版本或主后缀）。
• 如果Trunk Commit Build成功完成（它应该工作），Acceptance Test Stage将针对Integration环境部署和验证验收测试。 如果成功，新版本已准备好投入生产。 否则，如果在Commit Build或Acceptance Test Stage出现错误，则会恢复合并。