2 篇博文 含有标签「ArgoCD」

很多团队最早的测试环境都很简单：大家共用一套 dev，分支一提交，CI 构建镜像，然后更新部署仓库里的镜像 tag，最后由 ArgoCD 同步到 Kubernetes。

这套方式在团队规模小、需求串行推进时非常够用。但只要多个功能分支开始并行测试，问题就会迅速暴露：A 分支刚部署完，B 分支又覆盖了环境；测试同学发现一个问题，却很难判断当前环境到底对应哪个 PR、哪个 commit；开发排查时还要先问一句“现在 dev 上是谁的版本”。

很多团队一开始做 CI/CD，目标都很朴素：代码合并后自动构建、自动发到测试环境、必要时再推到线上。

但流程一旦长起来，事情就会慢慢变味：PR 要检查，主干要打版本，测试环境要发，生产环境也要发，最后所有逻辑都堆进一堆 YAML 和脚本里。等到哪次线上出了问题，大家才发现，自己拥有的不是一条可靠的交付链路，而是一团只能靠翻日志排障的自动化拼接物。

我这次想整理的，不是“怎么把 Gitea Actions 配起来”，而是怎么把一套通用应用交付流程拆成几个边界清楚、彼此可追踪的环节：PR 阶段做 AI Review，主干阶段沉淀版本事实，开发环境做快速镜像验证，生产环境则通过 GitOps 交给 ArgoCD 接管发布。