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

教程【免费下载链接】school-of-sreAt LinkedIn, we are using this curriculum for onboarding our entry-level talents into the SRE role.项目地址https://gitcode.com/gh_mirrors/sc/school-of-sre点击查看免费下载持续集成Continuous IntegrationCI是软件开发团队频繁整合代码变更的实践每一次整合都由自动化构建含测试验证以便尽早发现集成错误。本篇基于 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什么是持续集成CICI 是一种软件开发实践团队成员频繁地将各自的工作成果整合到一起。每一次整合都会由一次**自动化构建含测试**来验证从而以最快的速度发现集成错误——这正是持续二字的核心含义不是等到月底或季度末才合并代码而是每次代码变更都立即触发验证。在传统开发模式下团队成员各自在孤立的分支上开发代码变更不断累积直到计划中的构建日期可能是一个月甚至一个季度才合并结果是大量集成问题与构建失败集中爆发。CI 正是针对这一痛点提出的解法它把集成与验证的成本分摊到每一次提交上让问题在发生当天就暴露出来。CI 的三大基础要求持续集成要真正运转起来需要满足三个前提条件它们共同构成了 CI 的底层基础设施单一代码仓库Single Code Repository所有代码变更必须维护在同一个代码仓库中所有成员定期将变更推送到各自的功能分支feature branch。只有一个共享的事实来源集成才有意义。快速集成与自动化构建代码变更必须尽快与其余代码集成自动化构建随即发生并把结果反馈给提交者以便尽早解决冲突与错误。反馈越快修复成本越低。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 工具它们各自提供丰富的插件与集成能力工具定位Jenkins开源 CI 服务器插件生态庞大是本文实操环节的主角BambooAtlassian 出品的 CI 服务器与 Jira、Bitbucket 深度集成Travis CI面向 GitHub 仓库的云托管 CI 服务GitLab内置 CI/CD 能力的代码托管与 DevOps 平台Azure DevOps微软的云 DevOps 平台提供完整的 CI/CD 能力这些 CI 工具通过与各类构建、测试、质量工具的集成来完成任务构建与打包集成 Ant、Maven 等构建工具负责编译、打包出制品单元测试集成 JUnitJava、SeleniumWeb 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 流水线实操流程如下准备环境安装 Git 命令行工具与 DockerWindows 下使用 Docker Desktop 并确保运行 Linux 容器通过 Jenkins 官方教程在 Docker 上运行 Jenkins完成初始配置创建管理员用户等。若直接在本地安装 Jenkins还需安装 Maven。Fork 示例应用从 GitHub 上 fork 官方示例simple-java-maven-app克隆到本地。创建 Jenkins 项目登录http://localhost:8080点击Create a Job输入项目名simple-java-pipeline类型选择Pipeline在 Pipeline 配置页的Definition字段选择Pipeline script from SCM指示 Jenkins 从源码管理获取流水线SCM选择Git并在Repository URL中填入本地克隆仓库路径。编写 JenkinsfileJenkinsfile 是保存在代码仓库根目录的脚本文件包含流水线配置、阶段与指令。课程给出了声明式流水线的最小示例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 } } } }提交并运行保存 Jenkinsfile 后提交推送git add .、git commit -m Add initial Jenkinsfile、git push origin master回到 Jenkins 打开simple-java-pipeline点击Build Now即可在Build History中观察构建进度并通过Console Output查看日志。为流水线添加测试阶段真实 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 testpost - 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 能力演进。赞分享教程【免费下载链接】school-of-sreAt LinkedIn, we are using this curriculum for onboarding our entry-level talents into the SRE role.项目地址https://gitcode.com/gh_mirrors/sc/school-of-sre点击查看免费下载相关推荐MobX状态管理3个核心机制与5个实战技巧MobX状态管理3个核心机制与5个实战技巧 MobX是一个简单、可扩展的JavaScript状态管理库它通过透明的函数响应式编程TFRP让状态管理变得直Gitea持续集成自动化测试与构建流水线Gitea持续集成自动化测试与构建流水线 引言从手动部署到自动化流水线的转型 在现代软件开发中持续集成Continuous IntegrationCI后端代码托管研发协作CI/CDFindMy.py持续集成自动化构建与测试流水线FindMy.py持续集成自动化构建与测试流水线 ? 痛点开源项目质量保障的挑战 作为Apple Find My网络生态系统的Python实现FindMy上一篇如何免费恢复Windows 11任务栏拖放功能终极修复指南下一篇Atlantis 安全加固实战指南Terraform PR 自动化平台的安全威胁模型与完整防护配置创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考