升级策略与节奏

决定多久、什么顺序、什么流程升级 — 让升级成为常规而非英雄行为。

为什么

没有成文策略，升级只在被逼迫时发生 — CVE、被阻塞的功能、EOL 通知 — 每次都是紧急。策略反转这点：你按自己控制的节奏升级，以最小风险顺序（叶子依赖先于框架先于运行时），用排练过的流程。目标是让升级无聊。有书面策略的团队升级频率高 10 倍、事件少 10 倍，因为每次升级都小、经审查、可预期。策略也让入职变简单：新工程师读策略就知道怎么升级。

何时使用

策略写一次，然后践行。团队翻倍或采用新运行时/框架时 revisit。

如何做

1. 定节奏：patch = 每周自动，minor = 每周自动，major = 每季度计划
2. 定顺序：安全补丁 > 叶子依赖 > dev 依赖 > 框架 > 运行时（Node/Python）
3. 定门控：每个升级 PR 必过类型检查 + 单元 + e2e + staging 冒烟
4. 定回滚：每个升级在 flag 后部署或旧版本热备 1 小时
5. 定归属：Renovate 管 patch/minor，指定"升级队长"管每季度 major
6. 写入 UPGRADING.md：策略、节奏、顺序、回滚流程
7. 跟踪"升级债务"指标：落后 >1 大版本的包数；增长则告警

示例

# UPGRADING.md（放仓库根）
## 节奏
- patch/minor：Renovate，每周，全绿 CI 自动合并
- major：每季度，升级队长负责，人工审查

## 顺序（风险从低到高）
1. 安全补丁（立即，绕过节奏）
2. 叶子依赖（lodash、date-fns）— 爆炸半径低
3. dev 依赖（eslint、prettier）— 不进生产
4. 框架（React、Express）— 高爆炸，需 staging
5. 运行时（Node、Python）— 最高爆炸，需基建变更

## 门控
typecheck && unit && e2e && staging-smoke

## 回滚
每个 major 部署时旧镜像打 :prev 标签；
kubectl rollout undo 在部署后 1 小时内 <30 秒回滚。

## 债务指标
npm outdated --json | jq '[.[] | select(.current < .wanted)] | length'
Grafana 中落后 >1 大版本的包 >5 则告警。

常见问题

⚠无书面策略 — 每个工程师升级方式不同，团队无法判断跳过的升级是有意还是遗忘。
⚠同一 PR 升级运行时（Node）和框架（React）— 破坏时无法隔离是哪个导致。
⚠无债务指标 — 升级感觉良好，直到跑 npm outdated 发现 40 个包落后 2 个大版本。

最佳实践

✓写 UPGRADING.md 并从 README 链接 — 策略只在工程师能找到并遵循时有用。
✓在仪表盘跟踪升级债务指标（落后 >1 大版本的包数）；增长的线会逼出对话。
✓"升级队长"每季度轮换，使大版本升级的知识共享而非孤岛。