企业 GitOps 最佳实践
可靠的 Argo CD 落地依赖仓库和变更流程，而不只是 YAML 模板。团队应把“谁能改什么、怎样晋级、失败如何恢复、如何证明发布完成”变成可执行规范。
1. 仓库布局
推荐将应用源码与环境部署声明分离，或至少让部署目录的所有者和审批规则独立：
app-config/
├── applications/ # Application 与 ApplicationSet 声明
├── projects/ # AppProject、RBAC 相关声明
├── platform/ # 共享基线：Namespace、Quota、NetworkPolicy
└── apps/
└── user-center/
├── base/
└── overlays/
├── dev/
├── staging/
└── prod/
生产 overlay、Project 和 ApplicationSet 应使用受保护分支与 CODEOWNERS；开发者可提交变更，但不能绕过平台与应用责任人的审核。
2. 环境晋级与镜像版本
CI 构建完成后推送不可变镜像 tag 或 digest，并更新开发环境部署仓库。通过验证后，以 PR 将同一镜像版本晋级到测试和生产，而不是在每个环境重新构建。
代码提交 -> 构建 image:<git-sha> -> 更新 dev Git -> 自动同步
验证通过 -> PR 晋级同一 digest 到 staging -> PR 晋级到 prod
避免在生产使用 latest。Git commit、镜像 digest、Argo CD Application revision 和变更单号应能相互关联。
3. 发布与回滚
- 发布前确认 Application 为
Synced + Healthy，目标集群可用且无未处理告警； - PR 明确列出镜像版本、配置差异、数据库迁移、回滚步骤和责任人；
- 先在低风险环境验证，再按窗口同步生产；
- 发布后等待同步和健康检查，并验证关键业务探针；
- 失败时优先回退 Git 版本，再由 Argo CD 同步回一致状态；
- 若做紧急 CLI 回滚，事后必须提交等效 Git 回退。
4. 变更冻结与例外
冻结期应锁定生产部署仓库的合并权限和 Application 同步策略，而不是依赖口头通知。紧急变更需要明确批准人、影响范围、回滚条件与事后复盘；不要让“紧急”成为跳过 Git 审核的常态。
5. 发布前检查清单
- Git revision、镜像 tag/digest 与变更单一致；
- Application 的 Project、集群与 Namespace 符合环境边界；
- 渲染差异已审核，没有意外 Prune 或共享资源修改；
- 数据库迁移可回退或已完成备份验证；
- 自动同步、Self Heal、Hooks 的行为符合本次发布预期；
- 同步后将等待
Synced + Healthy并执行业务验证； - 回滚 Git commit、负责人和通知渠道已明确。
持续复盘同步失败、漂移、权限拒绝、发布耗时和恢复演练结果。把重复出现的问题沉淀为 Project 约束、仓库检查、CI 校验或平台基线，而不是依赖人工记忆。