3、流水线基础：CI/CD流水线概念、Jenkins/GitLab CI/GitHub Actions对比、Serverless流水线架构
3.1 CI/CD流水线核心概念
持续集成（CI）与持续交付/部署（CD）是现代软件工程的核心实践。CI/CD流水线将代码从提交到部署的整个过程自动化，确保每次变更都能快速、可靠地到达生产环境。
核心阶段： 代码提交 → 静态分析 → 单元测试 → 构建打包 → 集成测试 → 部署至预发布 → 验收测试 → 生产发布
流水线的核心价值在于：
- 快速反馈：每次提交后几分钟内获得测试结果，定位问题
- 消除手动操作：减少人为失误，提升发布频率
- 可重复性：相同代码、相同环境、相同流程，结果一致
- 质量门禁：每个阶段设置检查点，不合格代码无法进入下一阶段
3.2 主流CI/CD工具对比
Jenkins、GitLab CI、GitHub Actions是目前最广泛使用的三种CI/CD工具，它们在架构、配置方式、扩展性等方面存在显著差异。
| 对比维度 | Jenkins | GitLab CI | GitHub Actions |
|---|---|---|---|
| 架构模式 | Master/Agent 分布式 | Runner 分布式 | Runner 分布式（托管+自托管） |
| 配置方式 | Web UI + Jenkinsfile (Groovy) | .gitlab-ci.yml (YAML) | .github/workflows/*.yml (YAML) |
| 安装部署 | 需自建服务器，插件生态丰富 | SaaS或自托管，与GitLab深度集成 | SaaS为主，支持自托管Runner |
| 扩展性 | 插件驱动，1000+插件 | 内置功能丰富，少用插件 | Action市场，社区贡献活跃 |
| 并发能力 | 依赖Agent数量，可水平扩展 | 依赖Runner数量，自动扩缩容 | 按并发配额，付费可提升 |
| 容器支持 | 通过插件或Pipeline实现 | 原生支持Docker/Kubernetes | 原生支持Docker/容器化Job |
| 适用场景 | 复杂流水线、企业级定制 | GitLab生态、中小型团队 | GitHub生态、开源项目、快速启动 |
选型建议： 如果你的团队深度使用GitHub，优先选择GitHub Actions；如果使用GitLab自托管，GitLab CI是最佳选择；Jenkins适合需要高度定制化、多工具链集成的大型企业环境。
3.3 Serverless流水线架构
Serverless流水线将CI/CD的执行环境从传统的虚拟机/容器集群迁移到函数计算（FaaS）和托管服务上。每个流水线阶段被拆解为独立的函数或托管任务，按需执行、按量计费。
架构核心组件
- 事件源：代码仓库Webhook、定时触发器、手动触发
- 编排层：状态机/工作流引擎（如AWS Step Functions、阿里云FnF）
- 执行层：函数计算（如AWS Lambda、阿里云函数计算）执行测试、构建、部署任务
- 存储层：对象存储（如S3、OSS）存放构建产物、测试报告、缓存
- 消息队列：解耦任务依赖，实现异步执行（如SQS、RocketMQ）
与传统流水线的关键差异
| 特性 | 传统流水线 | Serverless流水线 |
|---|---|---|
| 资源模型 | 预留虚拟机/容器集群，持续运行 | 按需执行，无空闲资源消耗 |
| 计费方式 | 按资源时长付费（即使空闲） | 按执行次数+执行时长付费 |
| 弹性伸缩 | 需手动或自动扩缩容，有延迟 | 毫秒级弹性，自动扩展到任意并发 |
| 运维复杂度 | 需管理CI服务器、Agent集群 | 无需管理基础设施，聚焦业务逻辑 |
| 执行环境 | 固定OS/运行时，环境一致性高 | 函数运行时，冷启动可能影响首次执行 |
| 超时限制 | 无严格限制（可长时间运行） | 函数超时限制（通常15分钟/900秒） |
关键约束： Serverless流水线并非万能。函数超时限制要求将长时间任务（如大型集成测试、端到端测试）拆分为多个子阶段或使用异步回调模式。此外，冷启动延迟在测试任务频繁触发时可能影响整体效率，需要预热策略或预留并发。
Serverless流水线的适用场景
- 微服务测试：每个微服务独立流水线，测试任务轻量，触发频率高
- 按需测试环境：PR触发时临时创建测试环境，合并后自动销毁
- 多版本并行测试：利用Serverless弹性同时运行多个版本的测试套件
- 跨区域测试：在多个地域同时执行测试，验证全球部署一致性