一、gitops流程

• 开发人员在本地创建代码，推送到 GitLab 仓库。

• GitLab CI 监听代码仓库中的变化，当代码被推送到仓库后，触发 CI/CD 流程。

• CI 阶段，GitLab CI 运行各个 Job，在指定的 Runner 上执行测试、构建、代码分析等任务，构建contained镜像（应用名称：应用环境：应用版本-commit 短哈希）。

• CD 阶段，Argo CD 监听 Kubernetes 资源清单文件的变化，当发现新的清单文件时，自动拉取最新的 Docker 镜像，并将应用程序部署到 Kubernetes 集群中。

• Argo CD 可以自动检测应用程序的健康状态，并提供 UI 界面、命令行工具等方式来管理应用程序的部署、升级、回滚等操作。

二、持续集成（CI）

1、代码版本流程

A、gitflow（适用于一个开发周期多个版本并行）

• Master分支：主干分支，也是正式发布版本的分支，其包含可以部署到生产环境中的代码，通常情况下只允许其他分支将代码合入，不允许向Master分支直接提交代码（对应生产环境）。

• Develop分支：开发分支，用来集成测试最新合入的开发成果，包含要发布到下一个Release的代码（对应开发环境）。

• Feature分支：特性分支，通常从Develop分支拉出，每个新特性的开发对应一个特性分支，用于开发人员提交代码并进行自测。自测完成后，会将Feature分支的代码合并至Develop分支，进入下一个Release。

• Release分支：发布分支，发布新版本时，基于Develop分支创建，发布完成后，合并到Master和Develop分支（对应集成测试环境）。

• Hot fix分支：热修复分支，生产环境发现新Bug时创建的临时分支，问题验证通过后，合并到Master和Develop分支。

B、基于主干分支（适用于一个开发周期并行版本少的情况）

• master 分支

• 用于开发的主干分支，保证master 分支一直处于clean build 的状态

• release 分支

• 命名：release/<release version>, 例如：release/1.1.x

• 用于发布新的版本，发布时 打上git tag， 发布后如果有hotfix， 直接在release 分支上做bug修复， 并cherry pick 到master

• feature 分支

• 命名：开发名字/<需求>， 例如： chenjy/delivery-schedule

• 用于个人的功能开发，限于1-2 天的开发内容

• 及时合并到master 分支；如有需要， 发起PR， 及时通知reviewer

2、后端构建流程

• java应用打包

• 根据分支名称构建镜像（应用名称：应用环境：应用版本-b时间戳）

• 推镜像仓库

3、前端构建流程

在主工程

三、持续部署（CD）

1、argoCD部署应用的目录结构

2、持续发布流程