DevOps CI/CD 流水线搭建完整指南

Atlassian 在其持续交付指南中指出："流水线是可编程的基础设施，团队每次都可以获得期望的行为。"一条好的 CI/CD 流水线让团队专注于代码而非部署——这正是小团队能够高效交付的关键杠杆。

流水线设计三原则

快速反馈：Lint 和单元测试应在 5 分钟内完成。如果流水线超过 10 分钟，开发者开始"提交后去喝咖啡"，反馈循环断裂。GitHub 2026 年调研显示，等待 CI 超过 10 分钟的开发者，上下文切换频率增加 3 倍。

渐进式质量门禁：Lint → 单测 → 构建 → 集成测试 → 部署。任何环节失败立即停止，节省计算资源的同时提供最快速的失败反馈。

可重复性：同样的代码在任何时间触发流水线都应得到相同结果。使用 Docker 容器确保构建环境一致性，锁定依赖版本。

标准流水线六阶段

1. Lint & Format Check（1-2 分钟）：ESLint + Prettier + TypeScript 类型检查。这个阶段应该在开发者本地 pre-commit hook 中就完成，CI 仅作为兜底。

2. Unit Test（3-5 分钟）：Vitest / Jest 单元测试 + 覆盖率检查。设置覆盖率阈值（如 80%），低于阈值则流水线失败。使用 --shard 参数将测试拆分到多个 CI Job 并行执行。

3. Build（2-4 分钟）：生产环境构建 + 资源优化（代码压缩、Tree Shaking、CSS 提取）。构建产物作为不可变 artifact 存储，后续阶段直接使用。

4. Integration Test（5-15 分钟）：端到端测试（Playwright / Cypress）+ API 契约测试。使用 Service Container 启动依赖服务（数据库、缓存），测试完成后自动清理。

5. Deploy Staging：自动部署到预发布环境，执行 Smoke Test（核心流程冒烟测试）和性能基准测试。

6. Deploy Production：手动审批后部署生产（蓝绿部署或金丝雀发布），自动执行生产环境冒烟测试。如检测到异常指标（错误率、响应时间），自动触发回滚。

给小团队的建议

不要一开始就构建完美的流水线。从"最小可行流水线"开始：代码 Push → 单测 → 构建 → 部署到测试环境。跑通后逐步添加质量门禁。Atlassian 的建议非常务实："区分持续交付（Continuous Delivery）和持续部署（Continuous Deployment）——前者允许手动审批，后者完全自动化。对于大多数业务场景，持续交付已经足够，不必盲目追求持续部署。"

在迎临的实践中，我们为每个新项目默认配置包含 Lint + Test + Build + Staging Deploy 的基线流水线（使用 GitHub Actions，约 50 行 YAML），客户团队可以在 1-2 天内完成搭建并看到效果。