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

【问题标题】：Jenkins - How many CI/CD pipelines for a release?Jenkins - 一个版本有多少 CI/CD 管道？
【发布时间】：2019-06-08 00:30:17
【问题描述】：

使用以下 Git 工作流程，适用于任何版本，

对于持续交付，我的理解是，需要创建两条Jenkins管道，如下图：

1) 构建在每个 Feature 分支（绿色）合并到 Develop 分支（紫色）时触发的管道。 Pipeline 将在 Nexus 存储库中推送 product-x.y-snapshot.jar。这个 jar 的目的是用于 QA 测试

2) 在每个新的 Release 分支合并到 Master 分支时触发的发布管道。 Pipeline 将在 Nexus 存储库中推送 product-x.y.jar。这个 jar 直接投入生产。

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

1) 两条管道是否足以稳定发布？ product-x.y.jar 作为该版本的一部分添加了新功能

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

【问题讨论】：

【解决方案1】：

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

在这种情况下，您可以为每个暂存环境使用三个管道（或者一个带有用于选择和构建每种环境类型的参数的管道）。网上有很多Jenkins持续交付配置的例子。

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

【讨论】：

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