git - Git 流程和持续集成/持续交付

Question

我试图弄清楚将 Git 流与 CI/CD 管道一起使用所涉及的步骤（nb 交付而不是部署）

我想我可以有一份由推送到开发分支触发的 Jenkins 工作。另一个是在发布分支合并到主分支时触发的。以下是我认为可能涉及的粗略草图。这些是使用 Gradle 作为构建工具的 Java 项目，其中多个子项目作为存储库的一部分。

开发人员将更改推送到子项目远程开发分支

Jenkins 子项目开发分支管道

1. 子项目詹金斯的工作开始了
2. 运行子项目的增量构建
3. 如果通过发布快照 jar 和源到快照工件 repo/else 向开发人员发送电子邮件
4. 基于快照创建 docker 镜像
5. 推送 docker 镜像
6. 让 kubernetes 在开发服务器中启动 docker 映像
7. 运行进一步的测试（例如，非功能性的性能、验证码扫描等）
8. 如果将分支开发分支传递到子项目的新发布分支（版本在创建时确定）/否则向开发人员发送电子邮件
9. 从项目版本中删除快照，例如。1.0-SNAPSHOT 变为 1.0
10. 将更改合并到 master 并用版本和子项目标记它，例如。1.0-服务X
11. 将更改合并到开发中并将版本升级到新快照，例如。1.1-快照

Jenkins子项目主分支管道

1. 子项目詹金斯的工作开始了
2. 运行子项目的干净构建
3. 如果通过发布发布 jar 和源来发布工件 repo
4. 根据发布创建 docker 镜像
5. 推送 docker 镜像
6. 让 kubernetes 在 SIT 服务器中启动 docker 映像
7. 运行进一步的测试（例如，非功能性的性能、验证码扫描等）
8. 如果通过，kubernetes 在 UAT 服务器中启动 docker 映像
9. 运行进一步的测试（例如，非功能性的性能、验证码扫描等）
10. 发布准备手动部署到 Prod

所以 dev 管道合并到 master 会触发 master 管道。不过我有很多问题。

1. 我把它作为开发管道的增量构建，即不干净。这是快速反馈的好主意吗？
2. 关于快速反馈的类似说明，这是否应该跳过集成测试？
3. 如果是的话，我是否需要另一个管道来构建包含集成测试的开发分支的夜间构建。或者在主分支中运行集成测试是否令人满意？
4. 快照！我不确定这些是否适合 Gitflow？我需要它们吗？如果不是在开发管道的第 3 步，我将启动发布分支，使用新版本进行另一个构建，将其发布到工件等。

现在就可以了！

标签： gitgradlecontinuous-integrationgit-flowcontinuous-delivery