公司把CI/CD从Jenkins迁到GitHub Actions，三个月后我们又迁回来了

去年领导看GitHub Actions免费额度够用，界面也现代化，拍板把用了五年的Jenkins拆了。三个月后，灰溜溜迁回来。不是GitHub Actions不好，是我们用错了地方。

为什么想迁

Jenkins确实老，界面像上世纪的，插件管理麻烦，升级一次崩三个插件。GitHub Actions看起来美好：YAML配置、原生集成GitHub、社区Marketplace几千个Action、免费额度对中小团队够用。

领导算了一笔账：Jenkins服务器两台，维护成本每月几百刀，GitHub Actions免费额度覆盖，省下的钱买咖啡。

第一个月：蜜月期

迁移过程顺利，几个核心Workflow写出来，Push触发构建、PR跑测试、Release打镜像推仓库。YAML比Groovy脚本好读多了，新同事上手快。

Marketplace确实丰富，一个 actions/setup-java 搞定JDK环境，一个 docker/build-push-action 搞定镜像构建，比自己写Jenkinsfile省事。

第二个月：问题浮现

问题一：调试成本

Jenkins里Pipeline跑失败，点进去看Console Output，日志完整，哪步错了秒定位。GitHub Actions失败，日志分散在多个Step里，而且默认只保留90天，过期想看历史问题，没了。

更坑的是本地调试。Jenkins可以本地起个Docker容器跑Pipeline，GitHub Actions只能用 act 工具模拟，但 act 和真实环境差异大，本地跑通线上挂，来回折腾。

问题二：私有依赖

我们有内部Maven仓库，Jenkins里配好Credentials，拉依赖没问题。GitHub Actions里，同样配置，偶尔403，重试解决。查了半天，发现是GitHub的IP池动态变化，内部防火墙白名单跟不上，每次都要运维手动加IP。

后来换成GitHub的自托管Runner，但那就失去了"免维护"的优势，和Jenkins服务器有什么区别？

问题三：复杂Workflow

简单CI/CD没问题，但我们的流程复杂：构建→单元测试→集成测试→安全扫描→性能基准→多环境部署→通知。

GitHub Actions的YAML越长越难维护，嵌套Condition、Matrix策略、Step之间传数据，YAML的表达能力到极限。想拆成多个Workflow复用，发现Reuse Workflow的限制很多，输入输出类型不支持对象，只能传字符串。

Jenkins里用Shared Library，Groovy写函数，复用逻辑清晰。YAML里复用？复制粘贴，改一个地方漏三个。

问题三：Secrets管理

GitHub的Secrets按Repository管理，我们有几十个微服务，每个仓库配一套Secrets，轮换密钥时改到吐血。Jenkins有Credential Plugin，全局、文件夹、项目三级管理，批量更新一条命令。

后来用GitHub Environment Secrets，稍微好点，但和Jenkins的灵活度比还是弱。

第三个月：回退决策

领导问：省下的咖啡钱呢？我说：调试时间翻倍、Secrets管理成本、私有依赖问题，算下来没省，还亏了。

不是GitHub Actions差，是我们的场景不适合：

简单项目、开源项目、GitHub原生生态：GitHub Actions完美

复杂企业流程、私有依赖多、需要精细权限控制：Jenkins更灵活

现在的架构

简单项目（内部工具、文档站点）：GitHub Actions，省维护。

核心项目（支付网关、订单系统）：Jenkins，可控、可调试、可复用。

一句话总结

工具选型不是追新，是匹配场景。GitHub Actions和Jenkins不是替代关系，是互补关系。我们花了三个月学费，才想清楚。