有多少管道用于基于干线的开发？

Question

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

我的理解是，如果一个团队中有2-3个开发人员，并且拥有在预定义的时间(24小时)内提交更改的短暂特性分支，那么最好使用基于主干的开发，如下所示。团队中的开发人员每天多次向主干(主)提交他们的更改。

​

​

优势使用TBD:

对于TBD，有一个主分支和多个发布的分支。

何地as

在Gitflow中，有多个发布的分支来自长期存在的开发分支.

1)使用TBD，使用Jenkins需要多少管道？

( 2)每个管道的输入/输出是多少？

Answer 1

就我个人而言，我更喜欢基于集群的开发，而不管团队规模如何:)

发布分支的数量实际上不是由所使用的方法(TBD或其他什么)决定的，而是由业务原因决定的：

• 发布分支用于真正需要不同的、或多或少的冻结版本的产品，例如OS或嵌入式系统。这些需求的典型原因包括：
  • 验证所有发布质量标准所需的时间相当长，稳定软件需要将发布与持续开发隔离到下一个版本，以满足这些标准。
  • 需要同时维护多个版本--发布分支成为传递任何每次发布热修复的工具。

​

• 如果对单独的发行版没有严格的要求，那么发行版只能成为主开发和集成分支上的标记/标签--这才是真正的CD。每次提交时都执行CI/CD管道，每当它通过所有发布标准时，就会退出。

每个发布分支需要一个Jenkins管道，主开发分支需要一个Jenkins管道(如果不是直接从它释放的话)。