Git Jenkins-一个版本有多少CI/CD管道？

对于任何版本，使用低于Git的工作流程

对于连续交付，我的理解是，需要创建两条Jenkins管线，如下所示：

1） 构建在将每个功能分支（绿色）合并到开发分支（紫色）时触发的管道。管道将在Nexus repo中推送

product-x.y-snapshot.jar

。 这个罐子的用途是用于QA测试

2） 将每个新的发布分支合并到主分支时触发的发布管道。管道将在Nexus回购中推送

product-x.y.jar

。这个罐子直接投入生产

两个管道都对每个功能进行了自动测试。 在两条管道中运行相同数量的自动测试

---

1） 两条管道是否足以稳定释放<代码>产品-x.y.jar 在该版本中添加了新功能

2） 如果是，如何为构建和发布管道维护二进制工件？使用Nexus。。。请提供任何参考

1）这个问题没有一个正确答案-在大多数情况下，两个管道（一个用于功能分支，另一个用于主分支）足以创建稳定的发行版，但团队通常使用三个暂存环境（例如，请参阅文章中的详细信息）：

• 开发环境：用于开发（或功能）分支和运行自动化测试
• QA环境：为QA团队的测试提供更稳定的代码版本
• Prod环境：用于构建当前在主分支上的生产就绪代码

在这种情况下，每个登台环境可以有三个管道（或一个管道，其中包含用于选择和构建每种类型环境的参数）。互联网上有很多Jenkins连续交付配置的例子

---

2） 如果我理解正确，为了维护工件，您可以使用（参见示例）或将特定工件从Jenkins发布到Nexus。

QA环境的管道是否创建了任何二进制工件？QA环境通常不绑定到某个分支，部署到QA环境的代码对应于特定的git标记（在哪个分支上不重要，但通常在开发上）。从我上面提到的文章中：“许多团队忽略了GitFlow的标记部分，这可能是解决此问题的一个有用工具。QA环境代表一个候选版本，不管您是否正式这么称呼它。换句话说，您可以通过标记代码（即1.3.2-rc.1），或通过引用提交哈希或任何分支的头来指定代码（这只是提交散列的快捷方式）。无论如何，部署到QA环境的代码都对应一个唯一的提交。“QA管道只需要检查现有的工件，所以他们不需要创建新的工件。QA团队通常有自己的自动化测试（例如，冒烟、回归、功能测试等）。这就是为什么在这种情况下，您可以使用开发管道进行快速单元/集成测试，并使用QA管道进行其他（通常较慢）测试，而这些测试仅适用于QA团队。