school-of-sre 持续集成（CI）构建流水线实战指南：从代码提交到自动化构建测试

• 教程

持续集成（Continuous Integration，CI）是软件开发团队频繁整合代码变更的实践，每一次整合都由自动化构建（含测试）验证，以便尽早发现集成错误。本篇基于 school-of-sre 课程体系中的 持续集成构建流水线 章节展开，结合课程内的 CI/CD 导论、演进历史 与 Jenkins 实操实验，为你完整讲透 CI 的核心原理、工具生态与可落地的 Jenkins 流水线配置。读完本文，你将理解 CI 为什么是 SRE 与 DevOps 实践的关键一环，并能独立搭建一条包含构建与测试阶段的 CI 流水线。

持续集成流水线（Continuous Integration Pipeline）的四阶段示意：代码 → 构建 → 测试 → 发布

持续集成流程（Continuous Integration Process）：开发者 Push code 进入源代码仓库，CI/Build Server 自动执行 Build 与 Test

什么是持续集成（CI）

CI 是一种软件开发实践：团队成员频繁地将各自的工作成果整合到一起。每一次整合都会由一次**自动化构建（含测试）**来验证，从而以最快的速度发现集成错误——这正是"持续"二字的核心含义：不是等到月底或季度末才合并代码，而是每次代码变更都立即触发验证。

在传统开发模式下，团队成员各自在孤立的分支上开发，代码变更不断累积，直到计划中的构建日期（可能是一个月甚至一个季度）才合并，结果是大量集成问题与构建失败集中爆发。CI 正是针对这一痛点提出的解法，它把"集成与验证"的成本分摊到每一次提交上，让问题在发生当天就暴露出来。

CI 的三大基础要求

持续集成要真正运转起来，需要满足三个前提条件，它们共同构成了 CI 的底层基础设施：

1. 单一代码仓库（Single Code Repository）：所有代码变更必须维护在同一个代码仓库中，所有成员定期将变更推送到各自的功能分支（feature branch）。只有一个共享的事实来源，集成才有意义。

2. 快速集成与自动化构建：代码变更必须尽快与其余代码集成，自动化构建随即发生，并把结果反馈给提交者，以便尽早解决冲突与错误。反馈越快，修复成本越低。

3. CI 服务器（CI Server）：需要一台专门的 CI 服务器，一旦有成员推送代码，立即触发构建。构建通常包括将源码编译并转换为可执行文件（如 Java 的 JAR、Windows 的 DLL 等），这一步被称为打包（packaging）。

CI 构建流水线包含哪些阶段

一次典型的 CI 构建并非只是"跑一下编译"，它通常由以下阶段组成：

• 构建与打包：编译源码、运行构建脚本，最终产出可部署/可执行的制品（Artifact），如 JAR、DLL、WAR 等。
• 单元测试与代码覆盖率：构建过程必须执行单元测试（Unit Testing），并统计代码覆盖率（Code Coverage），用于衡量测试对代码的覆盖程度，倒逼测试质量提升。
• 可选附加阶段：根据团队需要，构建流程还可以加入**静态代码分析（Static Code Analysis）与漏洞检查（Vulnerability Checks）**等阶段，在合入代码之前先完成质量与安全关口。

从课程配套图示可以看出，完整 CI 流水线由 Code → Build → Test → Release 四个阶段顺次串联；而在实际流程中，开发者将代码推送（Push code）到源代码仓库后，CI/Build Server 便自动承接 Build 与 Test 两个核心环节——这正是"提交即验证"的落地形态。

主流 CI 工具生态

课程列举了业界几款流行的 CI 工具，它们各自提供丰富的插件与集成能力：

这些 CI 工具通过与各类构建、测试、质量工具的集成来完成任务：

• 构建与打包：集成 Ant、Maven 等构建工具，负责编译、打包出制品；
• 单元测试：集成 JUnit（Java）、Selenium（Web UI 自动化）等框架执行测试；
• 静态代码分析与安全：通过 SonarQube 进行静态代码分析、代码质量与安全扫描。

从传统构建到 CI 的历史演进

为什么 CI 如今成为软件工程的标准实践？课程 CI/CD 演进历史 给出了清晰的脉络：

• 瀑布模型时代：项目按计划周期（一个月到一季度）统一构建，变更在各自分支中积压，集成问题与构建失败频发；运维团队因缺少变更与配置文档，部署常常需要热修复（hot fix）和紧急补丁；开发与运维之间缺乏协作，交付周期被显著拉长。
• 敏捷方法论：主张以多次迭代增量交付功能，开发者以更小的增量提交代码、更频繁地发布。每一次代码提交都触发一次新的构建，集成问题被提前识别，构建过程与交付周期因此显著改善——这就是持续集成（CI）的由来。
• DevOps 与 SRE 的兴起：DevOps 文化打破了开发团队（追求更多功能变更）与运维团队（追求生产环境稳定）之间的壁垒，双方使用相同的工具与流程，配合度大幅提升。持续交付（CD）通过向多个预生产环境（staging environments）增量部署较小的变更，进一步缩短了从提交到生产的距离。

CI 在 CI/CD 体系中的位置

CI 并非孤立存在，它是 CI/CD 三大实践之一。课程 CI/CD 导论 将 CI/CD 拆解为三个层次：

• 持续集成（Continuous Integration）：频繁整合代码变更，每次整合都自动化构建与测试；
• 持续交付（Continuous Delivery）：将构建产物更频繁地部署到 SIT、UAT、INT 等非生产环境，自动执行集成测试与验收测试，生产部署往往仍需人工审批；
• 持续部署（Continuous Deployment）：在持续交付的基础上，将生产部署也完全自动化，通常需要配合特性开关（Feature Toggle）以便无需重部署即可关闭某个功能。

采用 CI/CD 带来的收益包括：显著减少集成问题、让团队更快地开发出内聚的软件、改善开发与运维的协作从而减少生产集成问题、以更小的摩擦更快交付新功能，以及在出现生产问题时更快定位并在下一个版本/补丁中修复。

Jenkins 落地实操：从构建到测试的 CI 流水线

理论之外，课程提供了基于 Jenkins 的完整动手实验（详见 Jenkins CI/CD 流水线实操），流程如下：

1. 准备环境：安装 Git 命令行工具与 Docker（Windows 下使用 Docker Desktop 并确保运行 Linux 容器）；通过 Jenkins 官方教程在 Docker 上运行 Jenkins，完成初始配置（创建管理员用户等）。若直接在本地安装 Jenkins，还需安装 Maven。
2. Fork 示例应用：从 GitHub 上 fork 官方示例simple-java-maven-app，克隆到本地。
3. 创建 Jenkins 项目：登录http://localhost:8080，点击Create a Job，输入项目名simple-java-pipeline，类型选择Pipeline；在 Pipeline 配置页的Definition字段选择Pipeline script from SCM（指示 Jenkins 从源码管理获取流水线），SCM选择Git，并在Repository URL中填入本地克隆仓库路径。
4. 编写 Jenkinsfile：Jenkinsfile 是保存在代码仓库根目录的脚本文件，包含流水线配置、阶段与指令。课程给出了声明式流水线的最小示例（Docker agent 版本）：

pipeline { agent { docker { image 'maven:3.8.1-adoptopenjdk-11' args '-v /root/.m2:/root/.m2' } } stages { stage('Build') { steps { sh 'mvn -B -DskipTests clean package' } } } }

• agent指定流水线的运行环境：docker表示启动一个指定镜像（此处为maven:3.8.1-adoptopenjdk-11）的新容器，args用于把宿主机的 Maven 本地仓库挂载进容器，避免每次构建重复下载依赖；
• stages中可定义多个阶段，这里的Build阶段执行 Maven 命令mvn -B -DskipTests clean package（-B为批处理模式，-DskipTests跳过测试，先只做清理与打包）。

若 Jenkins 直接安装在本地（无 Docker），需将 agent 改为any，使其在 localhost 上运行，并确保本地已安装 Maven 工具：

pipeline { agent any stages { stage('Build') { steps { sh 'mvn -B -DskipTests clean package' } } } }

5. 提交并运行：保存 Jenkinsfile 后提交推送（git add .、git commit -m "Add initial Jenkinsfile"、git push origin master），回到 Jenkins 打开simple-java-pipeline，点击Build Now，即可在Build History中观察构建进度，并通过Console Output查看日志。

6. 为流水线添加测试阶段：真实 CI 流水线通常包含 Build、Test 以及代码扫描等多个阶段。课程在原有基础上追加 Test 阶段，并在post -> always中通过junit步骤收集 Surefire 生成的测试报告：

stage('Test') { steps { sh 'mvn test' } post { always { junit 'target/surefire-reports/*.xml' } } }

完整的双阶段 Jenkinsfile 如下：

pipeline { agent { docker { image 'maven:3.8.1-adoptopenjdk-11' args '-v /root/.m2:/root/.m2' } } stages { stage('Build') { steps { sh 'mvn -B -DskipTests clean package' } } stage('Test') { steps { sh 'mvn test' } post { always { junit 'target/surefire-reports/*.xml' } } } } }

这里的要点：Test阶段执行mvn test；post -> always保证该步骤在阶段执行完成后无论成败都会执行，测试报告随后即可通过 Jenkins 界面查看。提交推送后再次触发Build Now，即可看到 Build 与 Test 两个阶段依次运行，一条完整的 CI 流水线就此建成。

持续集成与 SRE 实践

CI 流水线对 SRE 角色尤为重要。课程 结论章节 指出：监控、自动化与消除琐事（Toil）是 SRE 的支柱之一，SRE 需投入约 50% 的时间在自动化重复任务与消除 Toil 上，而 CI/CD 流水线正是实现这一目标的关键工具——它以更小、更规律、更频繁的构建交付高质量应用。同时，部署时间、成功率、周期时间（Cycle Time）、自动化测试成功率等 CI/CD 指标，是 SRE 观测产品质量、持续改善应用可靠性的重要数据源。

此外，SRE 还会借助 CI/CD 做两件典型的事：

• 基础设施即代码（Infrastructure-as-Code）：将每一项配置都作为代码维护，通过 CI/CD 流水线部署到生产环境，从而保证配置的版本化、跨环境一致性，并避免人工操作的失误；
• 流水线评审：审查应用 CI/CD 流水线，建议加入静态代码分析、安全与隐私检查等阶段，从源头提升产品的安全性与可靠性。

小结

持续集成通过"单一代码仓库 + CI 服务器 + 提交即构建测试"的机制，把集成成本摊薄到每次提交，配合 Jenkins 等工具的自动化流水线（构建 → 测试 → 可选的质量与安全扫描），显著缩短了软件交付周期。理解并落地 CI，是通往持续交付、持续部署乃至整个 DevOps / SRE 体系的第一步。你可以先按本文的 Jenkins 实验在自己的环境中跑通 Build + Test 双阶段流水线，再逐步加入静态分析与安全扫描等附加阶段，向完整的 CI/CD 能力演进。

• 教程