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

我想我可能会有一份詹金斯的工作,这是由推动发展部门触发的。另一个在发布分支合并到主分支时触发。下面是我认为可能涉及的大概情况。这些是使用Gradle作为构建工具的Java项目,其中有多个子项目作为存储库的一部分。

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

詹金斯子项目开发分支管道

2. 运行子项目的增量构建
4. 基于快照创建docker映像
5. 推送docker映像
6. 让kubernetes在开发服务器中启动docker映像
8. 如果将分支开发分支传递给子项目的新发布分支(创建时决定的版本)/否则向开发人员发送电子邮件
9. 从项目版本中删除快照,例如1.0—快照变为1.0
10. 将更改合并到master中,并用版本和子项目标记它,例如1.0-serviceX
11. 将更改合并到开发中,并将版本升级到新快照,例如1.1-snapshot

1. 子项目jenkins作业已启动
2. 运行子项目的干净构建
3. 如果将发布发布jar和源传递给发布artifactory repo
4. 基于发布创建docker映像
5. 推送docker映像
6. 让kubernetes在SIT服务器中启动docker映像
8. 如果通过,请kubernetes在UAT服务器中启动docker映像
10. 发布准备好手动部署到Prod

1. 我把它作为开发管道的增量构建,即不干净。这是一个快速反馈的好主意吗?
3. 如果是的话,我需要另一条管道,用于开发分支的夜间构建,包括集成测试。或者在主分支中运行集成测试是否令人满意?
4. 快照!我不确定这些是否适合Gitflow?我需要它们吗?如果不是在开发管道的第3步,我将启动发布分支,使用新版本进行另一次构建,并将其发布到artifactory等。