3

对于基于Gitflow的工作流,建议使用三个管道(Dev、QA 和 prod)。

我的理解是,如果一个团队中有 2-3 名开发人员,并且具有在预定义的时间(24 小时)内提交更改的短期功能分支,那么基于 Trunk 的开发是首选,如下所示。团队中的开发人员每天多次将更改提交到主干(主)。


在此处输入图像描述

使用待定的优势:

使用 TBD,有一个master分支和来自 master的多个Release分支。

然而

使用 Gitflow,长期存在的Develop分支有多个Release分支。


1) 使用 TBD,使用 Jenkins 需要多少个管道?

2)每个管道的输入/输出是什么?

4

1 回答 1

2

就个人而言,无论团队规模如何,我都更喜欢基于 Trunk 的开发 :)

发布分支的数量并不是由使用的方法(待定或其他)决定的,而是由业务原因决定的:

  • 发布分支用于真正需要不同的、或多或少冻结发布的产品,例如 OS-es 或嵌入式系统。此类需求的典型原因包括:
    • 验证所有发布质量标准需要很长时间,稳定软件需要将发布与持续开发隔离到下一个发布,以满足这些标准
    • 需要同时维护多个版本 - 发布分支成为交付任何每个版本的热修复的工具
  • 如果对单独的发布分支没有硬性要求,则发布只能成为主要开发和集成分支上的标签/标签——这确实是真正的 CD 归结为。每次提交都会执行 CI/CD 管道,只要它通过所有发布标准,就会发布。

每个发布分支都需要一个 Jenkins 管道,主开发分支需要一个 Jenkins 管道(如果您不直接从它发布)。

于 2019-01-18T22:02:44.130 回答