HelloWorld 发布检查指南

发布前检查可分四块：代码与构建、测试与质量、安全与合规、上线与监控。逐项核查版本号、依赖、测试覆盖率、数据库迁移、回滚策略、监控告警、发布说明和沟通，保证可回溯、可恢复、可观测。务求在最小损失下完成可控上线；执行smoke测试、金丝雀发布与灰度，确认关键路径在真实流量下稳定，确保日志与追踪完整，便于定位故障。

用最简单的话理解：发布检查就是把“搬家”拆成小步

想象把一家店搬到新地址。你不会等到所有箱子都塞车了才发现钥匙忘家里了；同理，软件发布前先把每一项“钥匙”按清单核对清楚，能大幅降低当天出错的概率。下面按费曼写作法，把复杂的概念拆成最基础的几块，再逐一讲清楚怎么做、为什么这样做，以及常见的陷阱和示例。

四大检查维度（先看骨架）

• 代码与构建：版本号、分支策略、依赖、构建产物一致性。
• 测试与质量：单元、集成、E2E、覆盖率、静态检查、漏洞扫描。
• 安全与合规：凭证、密钥管理、隐私条款、第三方许可、合规扫描。
• 上线与监控：部署流程、数据库迁移、回滚、监控、告警、发布沟通。

逐项清单（可直接打印执行）

1. 代码与构建

• 确认 Release 分支或 Tag 已创建并且通过 CI：强制通过主干 CI 绿灯再打包。
• 版本号语义化（SemVer）：Tag 格式如 vYY.MM.DD-xx 或 v1.2.3，写入发布说明并同步到二进制元信息。
• 依赖检查：执行依赖漏洞扫描（如 SCA），并锁定依赖版本（lockfile）。
• 构建产物一致性：同一源码在 CI、预发布、Release 三处产物文件哈希一致。

2. 测试与质量

• 单元测试：本次变更覆盖率阈值（例如不低于 70% 或比基线不低于 -2%）。
• 集成/合同测试：与外部服务的契约测试通过（API mock 与契约校验）。
• E2E/烟雾（smoke）测试：核心业务流（登录、下单、支付、关键 API）在预发布成功。
• 性能基线：响应时间、内存与 CPU 在可接受范围内；关键路径响应时间有性能预算。
• 静态分析与格式化：lint、type check（TypeScript、MyPy 等）无阻断性警告。

3. 安全与合规

• 密钥与凭证：无明文提交，所有凭证使用机密管理（例如环境变量或密钥库）。
• 权限最小化：部署账号与运行时权限经过审查，只开放最小必要权限。
• 数据与隐私：若涉及用户数据，确保隐私条款、数据脱敏与备份策略到位。
• 合规扫描：第三方依赖许可证、GDPR/CCPA/行业合规项（如需）。

4. 上线与监控

• 数据库迁移：迁移脚本经过回滚校验，支持幂等执行与短期在线迁移。
• 回滚策略：明确回滚点（版本 tag）、回滚步骤与人员责任。
• 部署窗口与节奏：选择流量低峰窗口，定义金丝雀/灰度策略与步长。
• 监控与告警：关键指标（错误率、延迟、吞吐、队列长度）在 Dashboard 就位并有告警阈值。
• 发布沟通：填写发布单，通知相关团队（客服、运维、产品、市场）并共享回滚计划。

实操示例与常用命令（贴近真实的指令）

下面给几个常见的 CI / 本地检查命令示例，按你常用工具替换即可。

• 本地构建与测试（示例）：npm ci && npm run build && npm test — –coverage
• 依赖扫描（示例）：scan-tool –project . –report（替换为你公司的 SCA 工具）
• SQL 迁移回滚校验（示例）：在预发布 DB 上执行 db-migrate up 与 db-migrate down，确保回滚无误。
• 烟雾测试脚本（示例）：一键执行核心 endpoint 校验并返回 HTTP 200。

发布时序建议（谁在什么时候做什么）

• 发布前 3 天：冻结非紧急变更、完成所有合并请求、开始预发布构建与完整回归。
• 发布前 1 天：执行完整回归测试、性能回归、依赖扫描，完成发布说明草稿并同步相关团队。
• 发布当天：按计划窗口执行部署，先金丝雀 1%→5%→20%→100%，每步观察 15–30 分钟。
• 发布后 0–2 小时：执行烟雾测试与用户关键路径抽样验证，监控告警静默期结束后确认稳定。

一个可复制的发布检查表（表格版）

遇到问题怎么办：简单的排查流程（快速定位）

• 首先检查最近的发布日志（什么时候、哪个组件、哪个节点）。
• 看监控：错误率、延迟、CPU、内存，哪个指标先变坏？
• 按“从外到内”排查：外部用户请求→负载均衡→应用实例→依赖服务→数据库。
• 若是数据库相关异常：先查迁移脚本与锁表情况，再看慢查询与连接数。
• 不能快速定位时：触发回滚保护（若回滚可在 10–30 分钟内完成且风险低），同时成立应急小组。

避免常见陷阱（来自实战的真坑）

• 只关注 CI 绿灯却忽视数据迁移：上线后才发现结构不兼容，这是最常见的问题。
• 缺乏可观测性：没有 tracing 或详细日志，事故定位耗时翻倍。
• 一次性全量发布：没有金丝雀与指标门控，问题范围扩大，回滚成本高。
• 沟通不完整：客服、市场没收到变更信息，出现用户投诉时处理被动。

把 AI 和人工结合起来做双重校验

用机器做重复、批量的检查（依赖扫描、代码静态分析、回归测试），用人工做语境性判断（发布说明、合规审核、用户沟通）。机器能把显而易见的问题拦下来，人工负责那些需要业务判断的边界条件。实践中把自动化检测设为门禁，把人工评审设为最后一道防线，会让整个流程既高效又稳健。

最后，给你一个轻量级模板（发布单正文示例）

标题：服务 X v1.2.3 发布（YYYY-MM-DD）
变更摘要：修复 A、优化 B、支持 C。
部署窗口：XX:YY – XX:YY（预计 30 分钟）。
回滚计划：回滚到 tag v1.2.2，预计 20 分钟；负责人：张三。
监控关注点：ERROR_RATE、P95 响应时、DB 连接数。
联系人：开发：张三；SRE：李四；QA：王五。

写到这里有点像给自己做笔记——不要把每一步都想得太神秘，按照清单一条条过就行。真实线上会有突发，但通过“把复杂拆小步”与清晰的责任分配，绝大多数情况都能在可控范围内处理好。