跳转至

SOP：Bug Fix

与新功能流程的主要差异：可豁免 OpenSpec（如果是恢复已定义的行为）；其他依然要走 PR + 测试。

决策树：要不要走 OpenSpec？

这是 bug 修复吗？
├─ 是恢复"原本就该有"的行为 → 可豁免 OpenSpec（commit 说明原因）
└─ 涉及修改既有行为 / 接口 / 数据契约 → 走 OpenSpec（按"新功能"流程）

标准流程（豁免 OpenSpec 时）

1. 接缺陷 CZTST-D-X
   - 拉缺陷全文 + 关联故事 / 用例
   - 看证据：截图 / 日志 / 控制台错误
   - 看历史相似缺陷

2. 复现
   - dev 环境复现 → 如果不能复现，先扩充复现信息
   - 加一个**失败测试**（这是修复成功的判据）

3. 修复
   - /test-driven-development（Superpowers）
   - 在测试驱动下改最小代码量

4. 自查
   - /pre-pr-review
   - /code-review
   - 单元测试通过

5. PR
   - 标题：`fix: 订单导出 GBP 列在 IE 显示乱码 #CZTST-D-512`
   - 关联缺陷 + 关联故事
   - 描述里说"为什么之前不对 + 现在怎么修 + 影响范围"

6. PR 合并 develop → CI → dev（QA 在 dev 验证；test/uat 回归走 release/test、release/uat 分支）
7. QA 在 dev 验证缺陷已修
8. 缺陷标"已修复" → 上线节奏跟新功能一样

紧急 Hotfix 流程（uat 阻塞性故障）

当前 uat 为准生产环境（无独立 prod）。

1. 钉钉 oncall 告警 → Tech Lead 决定走 hotfix
2. 创建 hotfix 分支：hotfix/<short-desc>-CZTST-D-X
3. 最小化改动 — 只改必要的代码
4. 跑 /pre-pr-review + 至少 1 名 senior approve
5. 合并到 release/uat → Jenkins 构建 → 直接 push czerp-gitops（main）
6. ArgoCD AutoSync 立即自动同步 → 紧急部署生效（无 PR 人审门）
7. 监控紧密观察 30min
8. 事故复盘（PingCode CZKB 事故复盘页）→ Sprint Retro 上讨论

易错点

  • ❌ "我只改了一行" 跳过测试 — 任何修复都要有失败用例 → 通过的循环。
  • ❌ Hotfix 顺便重构。Hotfix = 最小化改动。
  • ❌ 修了 bug 没回灌测试用例 → 同样的 bug 下次还会出现。
  • ❌ uat 紧急修复后忘记把改动同步回 develop / release/test 分支。

缺陷 → 用例化

修一个缺陷 = 永久产生一条新回归用例。

  • 把当时写的失败测试落到对应位置：前端/E2E 用例提交进 czerp-console/tests/e2e/（初始化后），后端补到对应业务服务模块的单测
  • 在 CZTST 创建一条"回归用例"（关联缺陷），下次自动跑

这是"缺陷一次不再来"的关键纪律。

关联