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 回答