📚 课程目录第2章 CI/CD工具选型

CI/CD工具选型：Jenkins、GitLab CI、GitHub Actions、CircleCI 对比

做CI流水线的第一步，往往不是写配置，而是选工具。我见过不少团队，一上来就拿Jenkins搭了一个很重的Master-Slave架构，结果半年后维护成本翻倍。也见过直接用GitHub Actions的小项目，因为免费额度香，但稍微复杂点的构建逻辑就开始头疼。所以，选对工具，能让后续的流水线设计事半功倍。

先别急着跟风。我自己的习惯是，先想清楚几个问题：团队的技术栈是什么？代码放在哪里？预算多少？需要多复杂的编排？把这些摸透了，再谈工具选型。下面这张表，是我近几年在几个项目里反复对比后的总结，算是一份快速参考吧。

特性	Jenkins	GitLab CI	GitHub Actions	CircleCI
开源/托管	完全开源，自托管	开源版+托管版(SaaS)	托管版(SaaS) + 自托管Runner	托管为主，支持自托管Runner
配置方式	Jenkinsfile (Groovy)	.gitlab-ci.yml (YAML)	.github/workflows/*.yml	.circleci/config.yml
插件生态	极丰富（1000+）	中等（模板+集成）	中等（Actions市场）	较少（Orb生态）
容器支持	通过Docker插件	原生支持Docker executor	原生支持Docker & 自定义容器	原生Docker & Machine executor
并发与伸缩	需手动配置Agent集群	自动伸缩（需配置Runner）	自动伸缩（有限制）	自动伸缩（按并发数计费）
学习曲线	陡峭（Groovy + 插件）	平缓（YAML）	平缓（YAML + 模板）	平缓（YAML + Orb）
适用场景	大型企业、复杂流水线	GitLab深度用户、中小团队	GitHub项目、快速启动	中大型项目、追求速度

Jenkins：老黄牛，但别让它包揽一切

Jenkins几乎是CI的“活化石”。我在一个金融项目里见过它同时跑着20多个流水线，插件装了一百多个，界面卡得要命。后来我帮他们清理了一次未使用的插件，又上了Pipeline as Code，才算稳住。

优点很突出：完全开源，插件生态无敌——你能想到的几乎都有。但代价是维护成本高，Master节点一挂，整个CI就瘫了。而且Groovy语法写多了容易踩坑，尤其是序列化问题，我因为@NonCPS用错，排查了整整半天。

⚠️ 个人避坑笔记

别让Master节点跑构建任务，哪怕是小型团队。一定用Agent分离。
尽量用Declarative Pipeline（声明式）代替Scripted，可读性高很多。
插件版本冲突是常事，升级前先备份JENKINS_HOME。

GitLab CI：一体化，真香

如果你整个研发流程都在GitLab上（代码、Issue、Wiki、容器仓库），那GitLab CI几乎就是无缝集成。我去年帮一个创业团队从Jenkins迁移到GitLab CI，配置量少了60%，而且CI/CD的可见性直接在MR里就能看到，开发体验提升巨大。

它的YAML配置逻辑很清晰：stages + jobs + only/except 规则，我习惯把所有Job都放进.gitlab-ci.yml，用include引用公共模板。注意一点：免费版的Runner数量有限制，稍大的项目建议自建GitLab Runner挂到Kubernetes上。

# 一个简单的GitLab CI示例
stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  image: node:18
  script:
    - npm install
    - npm run build

test-job:
  stage: test
  image: node:18
  script:
    - npm test
  only:
    - merge_requests

GitHub Actions：小快灵，但别贪免费额度

GitHub Actions是后来者的黑马。如果你的项目在GitHub上，用它真的是“开箱即用”。我记得有个Hackathon项目，从创建仓库到构建完Docker镜像部署到云上，只花了20分钟写YAML。

它的市场里有很多社区写的Action，比如actions/checkout、docker/build-push-action，直接uses就搞定。但有个坑：免费计划每月只有2000分钟，随便一个项目跑上10分钟，一天就吃掉300分钟，几天就超了。我有个小项目因为跑测试太频繁，月底收到邮件警告，才意识到要控制。

💡 我的个人技巧

利用workflow_dispatch事件做手动触发，避免所有Push都跑完整流水线。另外，把构建缓存挂到actions/cache上，能省30%以上的时间。

CircleCI：快，但也贵

CircleCI给我的第一印象就是“快”。它的并行机制很成熟，默认就有大量并发构建，而且缓存策略智能。我在一个App项目里对比过，CircleCI比GitLab CI快了将近40%——当然，也贵了不少。

它的配置是.circleci/config.yml，支持Orb（可复用的配置包）。我比较常用的是circleci/node@5.0.3来简化Node项目的设置。但说实话，免费版只有每月6000分钟的限额，对中型团队来说可能不够。而且它没有自带代码仓库，必须绑定GitHub或Bitbucket，多了一个依赖。

# CircleCI 示例（简化）
version: 2.1
orbs:
  node: circleci/node@5.0.3
jobs:
  build:
    executor: node/default
    steps:
      - checkout
      - node/install-packages
      - run: npm test
workflows:
  version: 2
  build-workflow:
    jobs:
      - build

选型建议：没有银弹，只有最合适的

讲完几个主流工具，我想强调一点：别只看功能列表，要结合团队习惯和基础设施。比如，你们团队所有人都在用Visual Studio Code + GitHub，那GitHub Actions肯定比Jenkins顺手。如果你们已经有一套Kubernetes集群，那自建GitLab Runner或者Jenkins On K8s都是不错的选择。

下面这张图是我自己总结的选型决策框架，希望能帮你快速定位。

最终建议：如果一定要我推荐

小型团队 / 个人项目：GitHub Actions（免费够用，集成简单）
中大型团队 / GitLab深度用户：GitLab CI（一体化体验，维护成本低）
需要高度定制 / 历史遗留系统：Jenkins（虽然重，但能解决一切奇怪的需求）
对构建速度有极致要求：CircleCI（花钱买时间，值得考虑）

最后说一句，没有哪个工具是完美的。我见过有人用Jenkins跑得飞起，也见过有人用GitHub Actions一个月超费。关键是理解自己团队的痛点，然后做出选择。下一部分，我们会拿GitLab CI做具体实战，从零搭一条完整的流水线——到时候我再把踩过的坑一个个抖出来。