跳转至

SOP：上线发版

把若干已合并的故事打成 release，逐级部署到 dev / test / uat。 当前没有独立 prod 环境，以 uat 作准生产验收；prod 上线为未来规划。

角色分工

角色 职责
Tech Lead 决定 release 包含哪些故事 + 排期
Dev 配合上线 / 立刻响应异常
QA release 候选版本测试 + 上线后回归
Ops 看 GitOps 直推 + ArgoCD AutoSync + 监控
PM 钉钉广播 + 跟客户沟通

标准流程

T-2 天：release 候选确定
T-1 天：test 环境跑全量回归（含 P0/P1/P2）
T-0：uat 部署（准生产验收）
T+1 天：观察 + 复盘

分支与环境对应（见 czerp-api Jenkinsfile）：develop → dev、release/test → test、release/uat → uat。 没有 master / prod 分支；三个环境的 ArgoCD Application 均为 AutoSync（targetRevision: main）。

T-2

1. Tech Lead 在 PingCode 创建 release 页（含包含故事 / 排除故事清单）
2. 钉钉群广播预期上线时间窗口
3. 通知 QA 准备 release 候选回归
4. Dev 检查依赖故事（如 OMS 依赖 FMS）是否都已合并

T-1

1. 把 develop 合并到 release/test
2. CI 构建 → ArgoCD 同步到 test 环境
3. QA 跑全量回归（P0/P1/P2，含手工 + AI 驱动）
4. 通过率 100% / 无 Blocker / Critical → 候选确认
5. 写 release notes（含本次包含的故事 + 已知风险）

T-0 上线（uat 准生产验收）

1. 选低峰期窗口（避开工作日中段）
2. 钉钉广播"开始上线"
3. 把 release/test 合并到 release/uat
4. Jenkins 构建 uat 镜像
5. Jenkins 直接 commit + push 到 czerp-gitops（main 分支，改对应 overlays/uat/patch-deployment.yaml 的镜像 tag）
6. ArgoCD AutoSync 立即自动同步（无 PR 人审门）
7. 监控滚动：Pod 是否一个个起来
8. 起来后跑 smoke：基础功能 / 关键 API
9. PM 协助跑业务级 smoke（下个真订单 / 查一次报表 / etc.）

当前镜像变更无人审关卡：Jenkins 推 gitops 后 ArgoCD 立即生效。 如需对 uat 镜像变更加人审，需改 Jenkinsfile 增 PR 步骤，或把对应 Application 的 AutoSync 改为 manual。

T+1 观察

1. 看 Prometheus：错误率 / 延迟 / JVM
2. 看 Sentinel：是否有意外熔断
3. 看 Skywalking：跨服务调用是否健康
4. 看日志中心：error 数量是否飙升
5. 24h 没异常 → release 标"成功"，更新 PingCode CZPRD 状态

回滚

任何阶段出问题 → 优先回滚：

1. 钉钉广播"回滚中"
2. argocd app rollback <service>-uat <history-id>
   # 或 kubectl rollout undo deployment/<service> -n uat
3. 监控 → 业务恢复
4. 调查根因 → 修复 → 重新走流程

ArgoCD Application 命名为 <service>-uat（见 uat-applicationset.yaml 的 {{index .path.segments 1}}-uat）。 因 AutoSync + selfHeal 开启，回滚后须同步把 czerp-gitops 上的镜像 tag 改回旧版（或 selfHeal 会把状态拉回当前 git），再调查根因。

回滚比 hotfix 安全，不要在环境里直接 patch。

灰度（如已开启 Argo Rollouts）

strategy:
  canary:
    steps:
      - setWeight: 10
      - pause: { duration: 5m }
      - setWeight: 30
      - pause: { duration: 10m }
      - setWeight: 100

每个 pause 期间观察： - 错误率不超过 baseline 2× - 延迟 P95 不超过 baseline 1.5× - 业务指标（订单量等）不异常

不达标自动 abort。

中间件 / 重大变更

如果 release 涉及：

  • 数据库结构 breaking change（重命名 / 删列）
  • Nacos 配置变更
  • 中间件版本升级
  • 跨服务契约变更

需要预先准备额外步骤：

1. 写专项变更方案文档（PingCode CZKB）
2. dev → test → uat 三级演练
3. 维护窗口公告（至少提前 24h）
4. 准备完整回滚预案 + 数据备份
5. 上线时同步 Tech Lead + 架构师待命

上线后忌讳

  • ❌ 上线后立刻关电脑下班（至少留 30 分钟观察）
  • ❌ 不写 release notes
  • ❌ 不通知 PM / 业务（他们要跟客户说话）
  • ❌ 出问题死撑不回滚（先回滚再调查）

与各角色的钉钉群约定

  • 上线前：广播预期窗口 + 涉及故事
  • 上线中：实时进度（开始 / Pod 起来 / smoke 完成 / 完成）
  • 上线后：广播完成 + 监控链接 + 已知风险
  • 异常：广播异常 + 行动计划（回滚 / hotfix / 接受 + 监控）

关联