CI/CD 流水线设计

概述

CI/CD（持续集成/持续部署）流水线是现代软件工程的核心基础设施。它将代码从提交到部署的整个过程自动化，确保每次变更都经过一致的构建、测试和部署流程。

流水线阶段

1. 代码提交与触发

流水线由代码仓库的事件触发：

常用触发条件:
- push:     分支推送（如 main、develop）
- pull_request:   PR 创建或更新
- tags:     标签推送（如 v1.2.3）
- schedule: 定时触发

2. 代码检查

在构建之前进行静态分析：

• Lint 检查：eslint、pylint、golint
• 代码格式化：prettier、black、gofmt
• 类型检查：TypeScript、mypy
• 安全扫描：代码依赖漏洞检查

3. 构建阶段

构建产出:
  语言类: 编译产物、打包产物
  容器类: Docker 镜像
  文档类: API 文档、组件文档

最佳实践:
  - 多阶段构建减小产物体积
  - 构建产物缓存以加速后续构建
  - 为构建产物生成唯一标识（如 commit SHA）

4. 测试阶段

测试金字塔自底向上：

单元测试:     快速反馈，覆盖业务逻辑
  覆盖率要求: >80%
  执行时间: <30秒

集成测试:     验证组件间协作
  涵盖: 数据库、API、外部服务
  执行时间: <5分钟

端到端测试:   验证完整业务流程
  工具: Cypress, Playwright
  执行时间: <15分钟

5. 部署阶段

环境晋升策略

开发环境 (dev):     自动部署，每次合并触发
测试环境 (staging):  自动部署，main 分支构建成功
预发布 (pre-prod):   手动触发或定时
生产环境 (prod):     手动审批 + 自动部署

部署策略对比

策略	零停机	快速回滚	成本
蓝绿部署	是	是	高（双倍资源）
滚动更新	是	慢	低
金丝雀发布	是	是	中
重建部署	否	否	最低

6. 验证与监控

部署后需要自动验证：

• 冒烟测试：核心功能的快速验证
• 健康检查：服务可用性检测
• 性能对比：与基线对比响应时间和错误率
• 日志分析：检查是否有新增异常

流水线设计原则

快速反馈

• 将耗时长的测试放在并行阶段
• 单元测试在 5 分钟内完成
• 通过 webhook 和通知实现即时反馈

幂等性

• 每个阶段可重复执行且结果一致
• 不依赖外部状态
• 构建环境在每次运行时保持干净

安全性

• 密钥不硬编码在流水线配置中
• 使用 secrets 管理敏感信息
• 构建产物签名验证

常见流水线示例

单体应用流水线

stages:
  - lint
  - test
  - build
  - package
  - deploy

微服务流水线

stages:
  - lint
  - unit_test
  - build_image
  - integration_test      # 并行
  - security_scan         # 并行
  - deploy_staging
  - e2e_test
  - deploy_production     # 需审批

前端应用流水线

stages:
  - lint_and_typecheck
  - unit_test
  - build
  - deploy_oss             # 部署到对象存储
  - cdn_cache_purge        # 刷新 CDN
  - lighthouse_audit       # 性能审计

工具选择

工具	适用场景	特点
GitHub Actions	GitHub 项目	生态丰富，配置简单
GitLab CI	GitLab 项目	内置注册表，Kubernetes 集成
Jenkins	大型企业	插件丰富，可定制性强
ArgoCD	Kubernetes 原生	GitOps 模式，声明式部署
Drone CI	轻量级团队	YAML 配置，Go 编写，性能好

总结

设计 CI/CD 流水线时，关注三个核心目标：快速（缩短反馈周期）、可靠（一致的构建和部署）、安全（保护交付链路）。从简单的自动化构建测试开始，逐步添加部署和验证环节，在迭代中持续改进。