2. 常见CI/CD工具概览
聊到CI/CD工具，市面上选项太多了。我用过的不下七八种，每种都有自己的脾气。说白了，没有万能工具，只有适不适合你团队场景的那个。
下面这张图，是我自己总结的工具对比维度。先有个整体印象，我们再一个一个掰开聊。
2.1 Jenkins —— 老牌王者，但有点重
Jenkins，圈内人都叫它“詹师傅”。它出道早，插件生态极其庞大。我个人习惯用Jenkins处理那些需要高度定制的场景，比如跨多云部署、需要对接老旧系统的流水线。
优点：
- 插件超2000种，几乎什么都能接
- Pipeline as Code 用 Groovy 写，非常灵活
- 自托管，数据不出网，安全可控
- 社区活跃，遇到问题大多能搜到
缺点：
- 安装配置繁琐，插件多了经常版本冲突
- 界面颜值一般，用户体验偏老式
- Master节点单点故障风险，需要额外做高可用
- 维护成本高，需要专门的运维去“服侍”它
避坑： 我曾经接手过一个 Jenkins 实例，里面积压了60多个插件从不更新。一到构建高峰就 OOM。后来我强制规定了插件版本锁定和定期清理制度，才稳下来。
2.2 GitLab CI —— 跟代码仓库绑死的全家桶
如果你团队已经在用 GitLab，那 GitLab CI 就是天然选择。我在项目中遇到过单仓库多模块的痛点，GitLab CI 的父子流水线正好能解。
优点：
- 与 GitLab 仓库深度集成，MR触发流水线非常顺滑
- 配置用 YAML，学习成本低
- 自带 Runner 管理，可以自托管也能用 SaaS
- 内置容器镜像仓库
缺点：
- 只认 GitLab，换个平台就得重写配置
- 免费版功能受限（比如仅有一条 CI/CD 队列）
- 复杂编排能力不如 Jenkins
小技巧： 如果你用 GitLab CI，建议将 .gitlab-ci.yml 拆成 include 模块，不然文件长了很难维护。
2.3 GitHub Actions —— 开源社区的福音
GitHub Actions 近几年势头很猛。我记得刚发布时，整个行业都比较兴奋。说白了，它让 CI/CD 配置变成了一堆可复用的 action 拼装。
优点：
- Marketplace 里 action 丰富，拿来就用
- 配置基于 YAML，语法直观
- 免费额度对开源项目非常友好
- 触发方式多样：push、PR、issue、schedule 等
缺点：
- 只支持 GitHub 仓库，不能用于 GitLab / Bitbucket
- 自托管 Runner 需要额外精力维护
- 调试时日志输出不够清爽，排查问题有点烦
举个例子，一个简单的 Go 测试工作流：
name: Go Test
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Go
uses: actions/setup-go@v5
with:
go-version: '1.22'
- run: go test ./...2.4 CircleCI —— 快，但藏着点贵
CircleCI 的执行速度在同类中出名。我记得有一次并行跑测试，CircleCI 的智能缓存帮我节省了将近40%的构建时间。不过，爽完一看账单就清醒了。
优点：
- 构建速度快，并行能力强
- 缓存机制成熟，能显著减少重复下载
- 支持 SSH 直连调试，排错方便
- 原生支持 Docker 和机器执行器
缺点：
- 免费额度很少，超过限额收费较高
- 配置语法有点特殊，Orb 虽然好但有一定学习成本
- 数据不出境？除非你买 Server 版，但价格感人
2.5 Travis CI —— 老牌 SaaS，但逐渐边缘化
Travis CI 在 GitHub 生态早期是主流。我曾经维护过一个开源项目，Travis CI 用了好几年，后来才切到 GitHub Actions。不是它不好，而是时代变了。
优点：
- 配置简单，示例丰富
- 与 GitHub 集成顺畅
缺点：
- 免费额度越来越紧，构建排队时间长
- 功能更新慢，已被 GitHub Actions 碾压
- 企业级支持偏弱
2.6 工具横向对比总表
下面这张表，我把五个工具的核心差异拉出来。你想想看你的团队最在意什么，对照着选。
| 维度 | Jenkins | GitLab CI | GitHub Actions | CircleCI | Travis CI |
|---|---|---|---|---|---|
| 部署成本 | 高（需运维） | 中（自带Runner） | 低（SaaS为主） | 中（SaaS/自托管） | 低（全SaaS） |
| 配置语法 | Groovy（陡峭） | YAML（中等） | YAML（简单） | YAML（中等） | YAML（简单） |
| 生态扩展 | 极强（2000+插件） | 强（内置 + CI/CD） | 强（Marketplace） | 中（Orb） | 弱（社区脚本为主） |
| 托管场景 | 自托管为主 | 自托管 / SaaS | SaaS为主 | 自托管 / SaaS | 纯SaaS |
| 构建速度 | 取决于硬件 | 中等 | 快（并行能力强） | 极快（缓存优化） | 慢（排队严重） |
| 适合团队 | 大型企业、高定制 | GitLab用户、中型团队 | 开源项目、小型团队 | 重视速度、愿意付费 | 个人或小项目 |
2.7 核心选择建议
是不是觉得有点眼花缭乱了？我建议团队在选型时，先回答三个问题：
- 你们用哪个代码平台？ GitLab 选 GitLab CI，GitHub 选 Actions，闭坑 Jenkins 也能上。
- 团队有没有专职运维？ 有，可以考虑 Jenkins 或自托管 Runner；没有，优先 SaaS 产品。
- 对构建速度有硬性要求不？ 有，CircleCI 或 GitHub Actions 的并行策略值得投资。
再啰嗦一句： 不要把工具选型当成技术炫技。我见过团队硬上 Jenkins，最后半年没人能维护。工具是服务业务的，不是反过来。
好，这一章我们先铺垫到这里。心里有这五张牌，后面讲具体管道搭建时，你会觉得顺很多。