3.3.0 集成了 Argo CD，但与笔者目前使用的 K8s 版本不兼容。目前遇到最主要的问题就是流水线制作完成的镜像如何更新到 Git 仓库，然后触发 Application 的同步。

　　为此笔者基于 KubeSphere v3.1.1 的流水线，根据笔者的场景，实现了 GitOps 的服务发布流程，作此记录，暂且称之为最佳实践。

　　基于 KubeSphere 的流水线，自动创建服务部署清单，自动创建服务 pipeline，提交到服务部署清单仓库，流水线风格统一，通过服务流水线发布版本之后在一段时间内可以回滚，实现 GitOps 方式管理服务部署清单和流水线清单，做到版本控制。

　　每个服务根据环境（用 top pipeline 创建服务流水线的时候需要选择）又划分为不同的文件夹。

　　注意：目前只提供最基本的部署清单：如果需要 Configmaps、Secrets、Ingress、增加环境变量、label 等，需要手动增加或修改。具体可以参考下面的实践说明文档。

　　每个服务的发布，流水线都隶属于一个 DevOps 项目下，如果这个 DevOps 项目不存在，则需要手动新建。

　　持久化参数信息：流水线运行时会将所填参数更新到 Pipeline CR 的 parameters 中（避免流水线执行失败后，重新运行时，需要重填参数）；

　　用 Git 命令行实现。一个 DevOps 项目下的多个 Pipeline 同时运行，一定程度可能会提交失败。比如：B克隆代码到本地，此时 A 提交一次，B 提交时就失败，需要重新 pull 后再提交。所以需要加重试机制，失败重新 pull。容易提交冲突，所以需要先 pull 再 push，并增加失败之后重试

　　开启自动同步后，默认是 3~4 分钟 sync，时间较长。如何及时触发 CD 同步？集成 argocd 命令行工具到 Agent 镜像中，新建一个 gitops 账号，并通过 RBAC 控制该账号的权限。

　　执行 argocd sync 命令也可能失败，需要加失败之后重试具体请参看：Argo CD 用户管理、RBAC 控制、命令行登录、App 同步。

　　审核阶段，如果点击“终止”，将回滚上一个阶段的镜像版本。正式环境发布之后（即流水线最后一步），可以点击“终止”回滚到上一个镜像版本（一般在新版本测试不通过的情况下点击“终止”），如果 30 分钟内没有点击，或者点了继续，本次发布流程将结束。回滚的时候，通过 git revert 命令回退某一次提交。

　　目前采用 Kustomize，kustomize 利用 overlay 机制覆盖某些配置，虽然在可定制化方面不如 helm，如：不支持模板语法和变量，但 helm 对于笔者来说太重。目前的场景采用 Kustomize，基本可以满足需求。

　　所以当 K8s 资源对象被修改时，Git 中清单没变化的情况下，不需要自愈修复，argocd 不会做还原；但下一次流水线发布版本时，Git 上的清单会发生变化，此时 K8s 资源会被还原。

　　引入了 GitOps，发现要做的东西更多了，但也确实带来很多好处。本文旨在记录分享笔者的 GitOps 落地经验，有些方案细节可能只适用于笔者当前的场景，笔者也处于摸索阶段。欢迎大佬们拍砖。

　　同时也期待 KubeSphere 服务的发布可以和流水线一条龙创建，将 GitOps 做的更易用，而不用在项目和 DevOps 项目之间切换；同时将灰度发布集成到流水线、可以回滚。