一套设计良好的 CI/CD 流水线是现代软件工程的核心基础设施。它不仅是自动化工具的组合，更是团队工程纪律的编码化体现。本文总结了过去几年我在项目中搭建和优化流水线的实战经验。

1. 分支策略

我们采用了一种轻量化的 Trunk-Based Development 变体：所有开发在特性分支上进行，但分支生命周期不超过 2 天。短命分支减少了合并冲突的概率，同时保持了持续集成的节奏。对于大型功能，使用 Feature Flag 来控制未完成功能的可见性，而不是长期维护一个集成分支。

2. 自动化测试分层

流水线中的测试按照执行速度和覆盖范围分为三层：

  • L1 — 单元测试（< 2 分钟）：每次 push 触发。覆盖所有工具函数、Hooks 和核心业务逻辑。
  • L2 — 集成测试（< 10 分钟）：PR 创建时触发。验证服务间交互、数据库操作和 API 契约。
  • L3 — 端到端测试（< 30 分钟）：合并到主干后触发。覆盖关键用户旅程，在类生产环境中运行。

3. 制品管理

我们遵循"一次构建，多处部署"的原则。Docker 镜像在 CI 中构建一次，通过镜像仓库在各环境间晋升：dev → staging → production。Git commit SHA 作为镜像标签，确保任意版本的可追溯和可回滚。

4. 部署策略

对于生产环境，我们使用蓝绿部署策略。每次部署时启动一组完整的新实例，健康检查通过后一键切换流量。同时保留旧版本实例 30 分钟，以便在出现问题时快速回滚。

5. 安全扫描集成

在流水线中集成了依赖漏洞扫描和 SAST 静态代码分析。依赖扫描在每次依赖变更时自动运行；SAST 作为 PR 门禁，阻断高危问题的合入。

总结

好的 CI/CD 流水线应让团队感知不到它的存在——代码提交后，一切自动运转，开发者只需要关注编码和 Code Review。如果你的团队还在为"手动部署到测试环境需要 10 分钟"而困扰，那么投资在流水线优化上的时间一定会带来超额的回报。