GitLab CI/CD实战：用流水线抓出Java满199包邮Bug

从一个运费边界Bug说起

电商系统里最容易被忽略的Bug往往藏在边界条件里。假设商城规则是“满199元包邮”，当顾客刚好买到199元时，运费应该是0元。但如果代码里把判断条件写成了“大于199”而不是“大于等于199”，刚好达到门槛的订单就会被多收10元运费。

这个错误在普通订单上看不出来——大额订单能正常通过，只有恰好卡在门槛上的订单才会暴露问题。B站UP主用一套完整的GitLab CI/CD流水线演示了如何自动拦截这类Bug：先写好测试用例固定预期，再让流水线在每次推送时自动运行测试、打包和部署，用提交编号追踪每一次运行结果。

测试先行：把业务规则钉死在断言里

演示项目是一个Java商城服务，接口金额统一用整数分表示：199元对应19900分，10元运费对应1000分。测试用例围绕门槛前一分、刚好门槛、门槛后一分三个位置展开，预期运费分别是10元、0元、0元。

关键做法是测试先写正确预期，不跟着错误代码一起改。每组数据都包含商品金额和应收运费，断言比较预期与实际。刚好门槛这一组要求返回0分，如果实际返回1000分，测试必须失败。此外还有五个接口用例检查响应、总计和无效输入。修复前后，两份测试文件保持不变——这样才能证明是先识别错误、再验证修复，而不是靠放宽检查换来通过。

流水线三阶段：测试、打包、部署

GitLab CI/CD的核心概念只有三个：Pipeline（流水线，整次运行）、Stage（阶段，任务分组）、Job（任务，具体命令）。演示配置里测试、打包、部署各是一组，每组刚好只有一个任务。外框包着阶段，阶段里包着任务，看清这个包含关系就能对照配置理解一次运行。

Runner领取任务并执行，这里使用Shell执行器直接调用主机工具，标签用来匹配Runner。测试任务调用Maven的Test，版本参数带上提交短编号作为构建版本，随后检查退出码——Maven返回非零就把失败传给任务，避免后续命令掩盖失败。测试报告即使失败也收集，方便在GitLab里定位哪一个用例出了问题。

打包任务调用Maven的Package输出可运行JAR，再为产物计算文件指纹。打包文件通过Archive构建产物传递给部署任务，部署使用同一个包，才能把通过检查的结果与预运行结果对上。

Runner与执行器

GitLab Runner 是实际执行 CI/CD 任务的代理进程，Pipeline 中定义的任务最终都由某个 Runner 领取并执行。Runner 可以全局注册，也可以绑定到特定项目。为了让不同的 Runner 处理不同类型的任务，GitLab 使用标签（tag）进行匹配：任务在配置中声明所需标签，只有携带这些标签的 Runner 才能领取该任务。演示中使用 Shell 执行器，意味着 Runner 直接调用主机上的 Maven 等命令，任务与主机环境共享文件系统；另一种常见方式是 Docker 执行器，每个任务在独立容器中运行，隔离性更好。截图文字提到“Cell 执行器”，可能是演示环境中的自定义名称，但核心机制仍是 Runner 通过标签领取任务并调用主机工具。理解 Runner 的角色有助于排查“任务为何一直 pending”这类问题。

失败流水线：一次推送拦下10元Bug

推送错误版本后，流水线编号66的结果是失败。测试失败后，打包和部署都显示跳过，没有继续执行。进入失败任务的日志，可以定位到刚好达到门槛的用例：预期运费0分，实际1000分，就是多出的10元。完整测试共8个，这一个失败就足以阻止后续交付。

日志里先找失败用例和预期实际的差别，再回到对应代码，修复方向就很明确：把大于改成大于等于，让刚好199元也进入包邮分支。两份测试保持不变，相同预期下先识别错误、再验证修复。

退出码与任务失败传播

Shell 执行器运行任务时，每条命令都会返回一个退出码（exit code），0 表示成功，非零表示失败。GitLab CI 默认将非零退出码视为任务失败，并立即停止该任务后续命令；如果配置了 allow_failure: false（默认），失败还会阻止同一阶段及后续阶段的任务。演示中特意检查 Maven 的退出码，是为了防止脚本中后续命令掩盖测试失败——即使 Maven 返回失败，如果后续命令成功，整个任务仍可能被标记为通过。通过显式检查 $? 或使用 set -e，可以确保失败向上传播。这也是为什么测试失败后打包和部署显示“跳过”：它们依赖测试任务成功，流水线在失败点即被拦截。理解退出码机制，才能正确设计任务脚本，避免“假绿灯”。

修复验证：绿色结果背后的证据链

修改后提交并推送到相同分支，GitLab按相同配置为新提交创建流水线编号67，三个任务都成功。测试任务里同样的8个测试通过，门槛金额现在和前后一分一起满足预期；打包任务生成当前提交的JAR并保存为产物；部署任务调用脚本把包交给演示主机，脚本等待服务响应并核对运费和版本。

绿色说明配置中的命令成功，但还要看测试数量、产物和实际响应，确认成功具体是什么。部署结束后独立请求一次商城：商品199元，运费0元，总计199元。构建版本带着修复提交的短编号，产物与运行文件的指纹一致，说明这次提交构建的包正在提供正确的结算结果，而不是旧服务没更新。

构建产物与文件指纹

构建产物（artifacts）是任务生成的、需要传递给后续任务或供用户下载的文件，例如 Maven 打包生成的 JAR。在 GitLab CI 中，通过 artifacts:paths 声明产物路径，任务成功后产物会被上传到 GitLab，后续阶段的任务可以自动下载这些产物。文件指纹（如 SHA-256 校验和）用于唯一标识文件内容：只要文件内容有任何变化，指纹就会不同。演示中为 JAR 计算指纹，并在部署后核对运行文件的指纹，可以确认运行的服务确实使用了本次构建的包，而不是旧版本或缓存文件。这是一种比“看任务绿色”更可靠的验证手段，尤其在部署脚本可能静默失败时，指纹比对能提供端到端的证据链。

可复用的CI/CD检查习惯

这条流水线能拦住多收运费的问题，是因为测试明确检查了门槛。换到其他项目，四个习惯同样成立：把业务规则写成测试，尤其是容易遗漏的门槛；用提交编号找到对应运行；从任务日志解释失败或成功；确认运行的服务使用了那次构建的包。做到这几点，就能读懂并复现一条从测试到部署的完整流水线。