Git流和持续集成/持续交付

Question

我正在努力弄清将Git流与CI / CD管道一起使用涉及哪些步骤（nb交付而不是部署）

我认为我可以有一个Jenkins的工作，该工作可以通过推送到开发部门来触发。当release分支合并到master分支时触发另一个事件。以下是我认为可能涉及的粗略草图。这些是Java项目，使用Gradle作为构建工具，而多个子项目作为存储库的一部分。

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

Jenkins子项目dev分支管道

1. 子项目詹金斯工作开始
2. 运行子项目的增量构建
3. 如果通过发布快照jar和源到快照工件仓库，否则将电子邮件发送给开发人员
4. 基于快照创建docker映像
5. 推送docker映像
6. 让kubernetes在开发服务器中启动docker镜像
7. 进行进一步的测试（例如，性能不正常，veracode扫描等）
8. 如果已将分支开发分支传递到子项目的新发行分支（在创建时确定版本）/否则将电子邮件发送给开发人员
9. 从项目版本中删除快照，例如。 1.0-SNAPSHOT变为1.0
10. 将更改合并到主文件中，并使用版本和子项目对其进行标记，例如。 1.0-serviceX
11. 将更改合并到开发中，然后将版本升级到新快照。 1.1-快照

Jenkins子项目主分支管道

1. 子项目詹金斯工作开始
2. 运行子项目的干净构建
3. 如果通过发布发布jar和发布发布人工仓库的来源
4. 基于发布版本创建docker镜像
5. 推送docker映像
6. 让kubernetes在SIT服务器中启动docker镜像
7. 进行进一步的测试（例如，性能不正常，veracode扫描等）
8. 如果通过，则kubernetes将在UAT服务器中启动docker映像
9. 进行进一步的测试（例如，性能不正常，veracode扫描等）
10. 已发布版本，可以手动部署到Prod

因此，通过dev管道合并到master会触发master管道。不过我有很多问题。

1. 我将其作为开发管道的增量构建，即不干净。这是快速反馈的好主意吗？
2. 关于快速反馈的类似注释，应该跳过集成测试吗？
3. 如果可以，我需要另一个管道来每晚进行一次包含集成测试的dev分支构建。还是在master分支中运行集成测试会令人满意？
4. 快照！我不确定这些如何与Gitflow相适应？我需要他们吗？如果不在开发流程的第3步，我将启动发布分支，而是使用新版本进行另一次构建，将其发布到工件等。

现在就可以了！