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

Question

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

这有两种方法:

1.使用开发分支

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

2.使用主分支:

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

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

Answer 1

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

没有亚历克斯。关键是成熟的团队能够在提交更改之前对其进行足够好的测试，因此没有“未经测试的提交”。功能分支是一个创可贴，可让您执行低质量的提交。删除创可贴，学习做高质量的承诺！ (4认同)
您只是避免未测试的提交的CI。使用CI管理master分支并且只提交到development分支就可以了。 (2认同)
我和我的团队每天针对某个特定功能向分支机构承诺超过20次。仅当功能完成后，我才能合并回或创建拉取请求。从字面上看，这等效于浏览所谓的高质量提交。除非工程师的硬盘发生故障，否则我们可以进行远程协作并保留工作。 (2认同)
我同意 @xpmatteo 的回答，但对我来说 CI 只适用于小功能。您无法集成未经测试的代码。但你无法测试未完成的功能。因此，如果功能不小，即无法在一天内完成和测试，那么根据定义你不能使用 CI，而 git-flow 应该更适合。 (2认同)

Answer 2

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

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

@BastianVoigt 抱歉，但我不同意这一点。如果您将 CD 视为严格的“这是您能做到的唯一方法”的定义，也许您是对的。但如果您将 CD 视为改进软件及其交付的指南，并考虑到不同的项目有不同的细微差别，那么肯定还有灵活性的空间。分支有助于在开发过程中增加焦点，可以轻松地打开拉取请求来讨论更改、改进更改等。它们不必是巨大的更改，我们可以确保开发分支始终稳定/准备好发布，并且真正这不是CD的主要目标吗？ (5认同)
使用 git-flow 你永远无法进行 CD，因为当你的代码位于不同的分支中时，你无法持续做好发布的准备。在发布之前，您总是需要将所有内容合并到主干。如果你想要CD，你不应该使用分支。 (2认同)

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出现错误,则会恢复合并.