CI工具选型：Jenkins、GitLab CI、GitHub Actions、CircleCI对比与选择策略

做模块化CI分层，第一步就要选对工具。这事我踩过不少坑。

2018年我给一个金融项目搭CI，一上来就拍板用了Jenkins。结果呢？团队就俩运维，光维护插件兼容性就占了一半时间。后来我学乖了——先看场景，再选工具。你想想看，工具没有的好，只有合不合适。

几个主力工具，我先说说我的体感

先说Jenkins。老牌、灵活、插件生态极其丰富。我在一个政府项目里用过它，那套环境的网络严格隔离，只能内网部署。Jenkins的Pipeline as Code+自定义插件帮了大忙。但它也有让人头疼的地方：插件版本冲突、界面老旧、启动慢。说白了，运维成本高，小团队慎用。

再说GitLab CI。我以前在SaaS创业公司待过，20人开发团队，代码仓库和CI都在GitLab上。感觉就两个字：省心。.gitlab-ci.yml写起来简单，include关键字天然支持模块化。问题是，私有化部署版（Self-Managed）有性能瓶颈，并发多了Runner容易卡。

GitHub Actions我最近两年用得最多。生态好，市场上有海量现成的Action，复制粘贴就能用。但对Monorepo支持不太好——你想对不同子目录触发不同流水线？没那么直接。我有个项目得用paths-filter外加矩阵策略才绕过去。

最后是CircleCI。速度快，缓存机制强。我在一个频繁迭代的移动端项目里用过，流水线跑一次比Jenkins快3倍。但CircleCI的YAML语法学起来有点奇特，尤其是或（or）和条件（condition）部分，新上手的人容易懵。

一张表格，把核心差异说清楚

我的选型策略——三步走

1. 先看团队规模和运维能力。运维小于等于2人？果断排除自搭Jenkins，优先考虑SaaS方案（GitHub Actions/CircleCI）。我见过一个10人创业团队非要自己搭Jenkins，结果每天光修Master节点就要半小时。
2. 再看模块化需求有多深。如果你的用例分层要大量复用Pipeline片段（比如共享的构建步骤、测试步骤），GitLab CI的Include机制和GitHub Actions的Composite Action都很顺手。Jenkins Shared Library虽然强大，但学习曲线陡。
3. 最后看网络和合规。政府、金融客户常常要求内网部署。这时候你只能在Jenkins和GitLab CI里选。我会建议：如果团队平时已经用GitLab管理代码，直接上GitLab CI，减少工具链数量。否则选Jenkins，因为它对各种老旧的LDAP、AD认证兼容最好。

避坑指南：我曾经掉进去的坑

• Jenkins的插件地狱：我曾为项目安装了80多个插件，结果升级一次Jenkins，一半插件报兼容性错误。建议：能用原生Pipeline做的事，不装插件。比如拉代码、编译、测试，Jenkins本身就能搞定。
• GitLab CI的Job超时：有一次我写的测试阶段跑了4小时还没结束，Runner被卡死。后来才发现是死循环。记得在.gitlab-ci.yml里加timeout限制。
• GitHub Actions的Secret覆盖：多环境部署时，我忘记把env变量的作用域细化，结果生产凭证被拉到了预发环境调试输出里——差点出事。一定用环境级别的Secret，别图方便写全局。
• CircleCI的缓存失效：它的缓存基于checksum，但如果你的yarn.lock没变但依赖本身变了（比如yarn的registry出了问题），缓存就会命中错误的旧包。我后来强制每周清一次缓存。

一个快速决策的SVG流程图

下面这张图是我现在每次做CI选型时都会参考的逻辑。我把它画出来，方便你对着自己的情况走一遍。

最后说两句心里话

选型不是一次性决策。我记得之前有个项目，前半年用CircleCI跑得飞快，后来公司被收购、安全策略收紧，不得不切换到自托管Jenkins。我带着团队花了两个周末重写流水线，但因为我们开始就定了模块化分层，底层共享逻辑都封装好了，迁移成本并不高。

嗯，这里要注意：不管你最终选了哪个工具，一定要把CI流程本身当成代码来维护。写好注释、版本控制、有代码审查。这样以后换工具，心里也有底。