浅谈持续集成工具：从简历包装到深夜 CI 跑崩的血泪史
北京某985计算机大三，秋招狗，K8s 爱好者，日常通勤1小时+深夜敲代码效率拉满。最近被 CI/CD 折磨得睡不着觉，遂提笔记录。
上周五晚上十一点半，我正对着 VS Code 里一行 npm run build 的报错抓狂——本地跑得好好的 JavaScript 项目，一推到 GitLab CI 就炸。错误信息就俩字：segmentation fault。我盯着屏幕，脑子里只剩一个念头：明天就是项目 deadline，产品经理已经在群里@三次了，而我的简历上还赫然写着“熟悉 DevOps 工具链”。
那一刻，我真的想砸电脑。
但冷静下来一想，这不就是秋招前最好的练兵场吗？毕竟现在哪个互联网公司面试不问你 CI/CD 怎么搞？不写个 Jenkinsfile 都不好意思说自己会自动化部署。于是，我决定把这段时间踩过的坑、掉过的头发、和凌晨三点与 Runner 对话的经历，好好梳理一遍，顺便给自己的简历加点“真实感”。
事情是怎么开始的？
去年双11期间，我们校内创业团队接了个外包项目：给一家本地生鲜电商做前端微服务重构。技术栈是 Vue3 + TypeScript + Vite，后端用 Go 写的 API。听起来很标准对吧？但问题出在交付流程上。
最初，我们靠手动打包、scp 上传、SSH 登录服务器重启服务。结果上线当天，测试同学发现首页白屏——因为某个 JS chunk 文件没传全。运维大哥当场黑脸：“你们这流程，比我家楼下煎饼摊还原始。”
更惨的是，我投出去的几份实习简历上写着“熟悉 CI/CD”，结果面试官一问：“你用过哪些 CI 工具？怎么配置多阶段构建？” 我支支吾吾说“本地能跑就行”，HR 微笑挂断。
痛定思痛，我决定：必须上 CI！
选型：Jenkins 还是 GitLab CI？
作为云原生爱好者（其实就是 K8s 玩多了），我第一反应是 Jenkins —— 毕竟老大哥，插件多，社区强。但一想到要自己搭 Jenkins master、配 agent、管理 credentials……还要在简历上写“维护 Jenkins 集群”，我就头大。
再看我们项目本身：代码托管在 GitLab，团队就五个人，需求迭代快，没人愿意花时间运维 CI 系统。GitLab CI 原生集成、YAML 配置、共享 Runner 开箱即用——香！
于是果断选择 GitLab CI。而且，GitLab Runner 支持 Docker executor，正好和我们容器化的部署方式对齐。
第一次 CI 配置：JS 项目的坑真多
我兴冲冲写了第一个 .gitlab-ci.yml：
stages:
- build
- test
- deploy
build_job:
stage: build
image: node:18
script:
- npm install
- npm run build
artifacts:
paths:
- dist/
本地测试没问题啊！但一推代码，CI 直接失败：npm WARN deprecated ... 倒是小事，关键是 npm install 跑了 8 分钟，Runner 超时了。
问题1：依赖安装太慢
解决方案：用 pnpm 替代 npm，速度快 3 倍，且支持缓存。加上 cache 配置：
cache:
key: ${CI_COMMIT_REF_SLUG}
paths:
- .pnpm-store/
问题2：Node 版本不一致
本地是 Node 18.17，CI 默认镜像却是 18.0，某些 ES2022 语法直接报错。解决：锁定镜像版本，比如 node:18.17-alpine。
问题3：环境变量缺失
项目里用了 VITE_API_BASE，本地通过 .env 加载，但 CI 里没有。GitLab 提供了 Variables 功能，在 Settings > CI/CD 里配置即可，安全又方便。
改完这些，build 终于稳了。但很快，新问题来了。
多环境部署：dev/staging/prod 三重奏
产品经理说：“我们要有 dev 环境给前端联调，staging 给测试验收，prod 才对外。” 行吧，那就搞三个 job。
deploy_dev:
stage: deploy
script:
- kubectl set image deployment/frontend-dev *=my-registry/frontend:$CI_COMMIT_SHORT_SHA
only:
- develop
deploy_staging:
stage: deploy
script:
- kubectl set image deployment/frontend-staging *=my-registry/frontend:$CI_COMMIT_SHORT_SHA
only:
- staging
deploy_prod:
stage: deploy
script:
- kubectl set image deployment/frontend-prod *=my-registry/frontend:$CI_COMMIT_SHORT_SHA
only:
- main
when: manual # 手动触发，保命
这里有个细节：prod 部署必须 manual。不然哪天手滑 merge 到 main，半夜报警电话打爆你手机——别问我怎么知道的。
另外，K8s 部分其实用了 Helm，但为了简化没写出来。实际项目中，我们把 Helm chart 打包进 CI artifact，再在 deploy 阶段 apply，更规范。
真实事故：CI 成了瓶颈
上个月，团队同时推进三个 feature，每天 push 几十次。GitLab 共享 Runner 排队排到怀疑人生，一个 job 等 20 分钟才跑。
运维同学建议：“你们自己搭个 Runner 吧，用 K8s autoscale。”
于是我花了周末两天，基于 gitlab-runner Helm chart 搭了个自动扩缩容的 Runner 集群。关键配置如下：
# values.yaml
runners:
config: |
[[runners]]
[runners.kubernetes]
namespace = "ci"
image = "ubuntu:20.04"
privileged = true
[runners.cache]
Type = "s3"
Shared = true
配合 HorizontalPodAutoscaler，根据 CPU 和 pending jobs 自动扩容。从此 CI 平均等待时间从 15 分钟降到 47 秒。那一刻，我觉得自己终于配得上简历上那句“熟悉云原生 CI/CD”。
CI 工具横向对比：别光听 HR 吹
秋招面了十几家公司，发现大家用的 CI 工具五花八门。我整理了个小表格，结合自己体验：
| 工具 | 优点 | 缺点 | 适合场景 |
|---|---|---|---|
| GitLab CI | 与代码仓库无缝集成，YAML 简洁 | 高级功能需付费（如 DAG） | 中小团队，GitLab 用户 |
| GitHub Actions | 生态强大，Marketplace 插件多 | 国内访问慢，自建 runner 麻烦 | 开源项目，GitHub 用户 |
| Jenkins | 插件丰富，高度可定制 | 运维成本高，配置复杂 | 大型企业，遗留系统 |
| Tekton | 云原生，K8s 原生 CRD | 学习曲线陡峭 | K8s 深度用户 |
我个人建议：小团队优先选 GitLab CI 或 GitHub Actions，省心；大厂可能用 Jenkins 或自研平台（比如字节的 Lark CI），但面试时你说“用过 Jenkins”基本够用。
给秋招同学的建议：别让 CI 成为简历黑洞
很多同学（包括之前的我）在简历上写“熟悉 CI/CD”，结果连 pipeline 是啥都说不清。其实，面试官真正在意的不是你会多少工具，而是：
- 能否理解 自动化构建的意义（减少人为失误）
- 是否考虑过 缓存、安全、权限 等工程细节
- 有没有处理过 CI 失败后的排查流程
所以，哪怕你只用过 GitHub Actions，只要能把下面几点讲清楚，就比瞎写“精通 DevOps”强：
- 你的 pipeline 分几个 stage？为什么这么分？
- 如何避免重复安装依赖？（答 cache 即可）
- 敏感信息（如 API key）怎么管理？（答 CI Variables / Vault）
- 如果 CI 跑挂了，你怎么 debug？（答查看日志、复现本地、检查环境差异）
顺便说一句，我现在简历上改成：“基于 GitLab CI 实现前端项目自动化构建与 K8s 多环境部署，平均部署耗时 <2min”。HR 看了直呼专业。
写在最后
CI/CD 本质上不是炫技，而是让开发更专注业务逻辑，而不是重复劳动。那些深夜加班手动部署的日子，真的该结束了。
虽然我现在还是会遇到 CI 跑崩、Runner OOM、K8s rollout 卡住的问题，但至少，我不再害怕在简历上写它了。
而且，每次看到绿色的 pipeline ✅，那种“一切尽在掌握”的感觉，真的会上瘾。
对了，今天又收到一个面试邀请，岗位要求写着：“熟悉持续集成工具”。我笑了笑，打开 .gitlab-ci.yml，默默加了一行注释：
# This pipeline got me a job. Thank you, CI.
P.S. 如果你也在北京准备秋招，欢迎交流云原生 or 刷题经验！通勤路上聊聊 K8s，总比刷短视频强（bushi）。
评论 0