跳到主要内容

CI/CD

CI(持续集成)在每次合并前自动验证;CD(持续交付/部署)在验证通过后晋升产物到环境。目标:反馈快、失败可定位、发布可重复。

流水线阶段(参考模板)

阶段典型任务失败即阻塞
安装锁定依赖、缓存
静态检查lint、format、类型检查
单元/组件测试快测、覆盖率阈值(可选)
构建编译、打包、镜像
集成/契约DB 容器、Pact、OpenAPI diff是(有边界时)
安全依赖漏洞扫描、密钥扫描视严重级
部署staging → 人工批准 → prod环境策略

原则:越早失败越便宜;分钟级反馈优于小时级夜间批跑。

质量门禁

门禁说明
主分支保护禁止直接 push;要求 PR + 状态检查
必需检查test, lint, build 名称与分支规则一致
覆盖率不设虚荣 100%;关注关键包下降
契约消费者 job 拉 provider 契约
产物不可变同一 commit 构建同一 digest
注意

仅部署不验证:上线脚本绿但无测试 = 手动 CD。至少保证合并前跑完核心测试。

环境与晋升

环境用途数据来源
local开发本地/种子
previewPR 预览合成或脱敏快照
staging发布前整体验证脱敏生产子集
production用户流量生产

晋升规则示例:

  • main 合并 → 自动 staging
  • tag v* → 生产(需 approval)
  • 数据库迁移:向前兼容一步(expand → deploy → contract)

部署策略

策略适用注意
滚动无状态服务就绪探针、maxUnavailable
蓝绿要快切换双倍资源、会话粘滞
金丝雀风险敏感指标回滚自动化

移动端与前端见 移动端前端 的商店/静态托管流程。

可观测与回滚

  • 发布关联:commit SHA、构建号、变更单
  • 黄金信号:延迟、流量、错误、饱和度
  • 回滚:上一镜像/构建重新部署;DB 回滚需提前设计(向前兼容迁移)

个人项目最小 CI(GitHub Actions 思路)

# 示意:on pull_request + push to main
# jobs: lint → test → build

仓库内保持单一 workflow 文件、缓存依赖、矩阵仅在有多个运行时版本时启用。

相关篇章