2025 年别再使用 Jenkins！

阻碍你前进的遗留巨头

认识一下 Janet。她是一家中型科技公司的 DevOps 工程师，工作了五年。每个周一早上，她都会像闹钟一样，为不可避免的事情做好准备：“Jenkins 服务器又宕机了。”或者“构建失败了，没人知道为什么。”又或者她最喜欢的那句，“我们需要更新所有的 Jenkins 插件，但我们担心一切都会崩溃。”

听起来很熟悉？你并不孤单。

Jenkins 在过去的 15 年里一直是首选的 CI/CD 工具。它就像那辆老旧的家庭汽车，虽然总是进修理店，但你仍然保留着，因为，嗯，你习惯了它。但正如你在 2025 年不会再使用翻盖手机一样，现在或许是时候重新审视你与 Jenkins 的关系了 😒。

为什么 Jenkins 正在显露老态

Jenkins 在 2005 年推出时是革命性的。但 iPod 也是。技术发展迅速，曾经的尖端产品很快就会过时。以下是 Jenkins 正在落后的原因：

让安全团队彻夜难眠的安全漏洞: Jenkins 有着令人不安的安全问题历史。仅在 2021 年，Jenkins 安全团队就披露了 30 多个漏洞，并且新的漏洞还在不断出现。许多组织以提升的权限运行 Jenkins，这使得这些漏洞尤为危险。以 Acme Corp（化名）为例。他们的 Jenkins 实例通过 CVE-2023–27898 被攻破，这是一个在脚本安全插件 (Script Security Plugin) 中的关键漏洞。攻击者获得了他们生产凭证的访问权限，并在其基础设施中部署了加密货币挖矿程序 (crypto miners)。清理工作让他们花费了三天的工程时间，并损害了客户信任。
拖慢整个团队效率的性能问题: “我趁构建运行的时候去喝杯咖啡”这不仅仅是开发人员的玩笑，更是一个生产力问题。Jenkins 实例通常会随着时间的推移变得越来越慢，特别是当你添加更多作业和插件时。Michael，一个游戏初创公司的开发人员，描述了他的经历：“我们的 Jenkins 构建以前需要 10 分钟。在增加了两年功能和测试之后，它们需要 45 分钟。我们花在等待 Jenkins 上的时间比实际编码的时间还要多。”
滋生“Jenkins 专家”的配置复杂性: Jenkins 的灵活性是有代价的：复杂性。组织往往最终只有一两个“Jenkins 大师”，他们是唯一了解一切如何运作的人。当他们去度假或离开公司时，恐慌就会随之而来。一位工程经理曾这样说：“我们有超过 200 个 Jenkins 流水线，每个的配置都略有不同。没人敢碰它们，因为我们担心它们会中断。这简直是最纯粹的技术债。”
消耗资源的维护开销: 自行托管的 Jenkins 需要持续维护。

你需要：

管理 Jenkins 服务器本身
定期更新 Jenkins 核心
更新几十甚至上百个插件
处理备份和灾难恢复
配置和维护构建代理 (build agents)

这些维护工作不会增加业务价值；它只是为了维持系统运行。

GitHub Actions：现代替代方案

Janet 的故事有一个圆满的结局。她的团队从 Jenkins 迁移到了 GitHub Actions，周一早上的“救火”式应对也成为了历史。

GitHub Actions 代表了一种截然不同的持续集成/持续部署 (CI/CD) 方法：

内置安全性，无需维护服务器 : GitHub Actions 在 GitHub 的云中运行。你无需担心 Jenkins 服务器的安全或应用安全补丁。GitHub 的安全团队会为你处理这些。最好的安全服务器是你根本无需管理的服务器。
自动扩展的性能：需要更多构建能力？GitHub Actions 会自动扩展以满足需求。你可以并行运行构建，而无需管理额外的构建代理。Janet 的团队在迁移到 GitHub Actions 后，构建时间缩短了 60%，仅仅是因为他们可以并行执行测试，而无需担心基础设施 (infrastructure) 限制。
人人都能理解的代码化配置：GitHub Actions 使用直接存储在你的代码仓库 (repository) 中的 YAML 文件。这种方法有几个优点：

配置与它所构建的代码共存
变更通过常规代码审查 (code reviews) 进行追踪
新团队成员可以快速理解设置
无需专业知识

一位开发人员报告说：“GitHub Actions 的学习曲线比 Jenkins 平缓得多。我可以在一个下午，而不是几周内，理解我们整个 CI/CD 流水线。”

零维护开销：使用 GitHub Actions，你将拥有：

无需维护服务器
无需更新插件
无需配置构建代理
无需管理备份

这让工程师可以将时间投入到实际的产品开发中，而不是基础设施的维护。

实际影响

让我告诉你 Realtime Analytics, Inc. 从 Jenkins 切换到 GitHub Actions 后发生了什么。

在切换之前，他们有：

两名全职工程师专门负责 Jenkins 维护
每周发生的故障影响开发者生产力
平均构建时间 35 分钟
定期出现安全隐患，需要紧急修补

切换到 GitHub Actions 六个月后：

两名工程师都被重新分配到产品开发工作
零 CI/CD 故障
构建时间缩短到 12 分钟
安全问题由 GitHub 自动处理

他们的 CTO 估算，仅工程时间一项，这项改变每年就为他们节省了大约 30 万美元，这还不包括改善的开发者体验和更快的上市时间。

切换：比你想象的更容易

从 Jenkins 迁移到 GitHub Actions 的想法可能看起来令人生畏，但实际上它比你想象的要简单直接得多。

这里有一个简化的方法：

从一个小型、非关键项目开始
将其 Jenkins 流水线 (pipeline) 转换为 GitHub Actions 工作流 (workflow)
并行运行这两个系统以建立信心
随着团队适应，逐步迁移更多项目

GitHub 甚至专门为 Jenkins 用户提供了迁移指南和示例。

GitHub Actions 完美吗？不，但它是一个重大改进

公平地说，GitHub Actions 并非没有局限性：

对于非常专业的构建要求，你可能需要定制解决方案
如果你没有使用 GitHub 进行源代码管理 (source control)，集成就不会那么无缝
一些复杂的 Jenkins 设置可能需要你重新思考方法

然而，对于绝大多数开发团队来说，GitHub Actions 几乎在所有方面都代表着对 Jenkins 的巨大改进。

总结

Jenkins 多年来一直为我们服务得很好，但软件开发已经演进。现代的 CI/CD (持续集成/持续交付) 解决方案，例如 GitHub Actions，专为当今的开发实践而设计：云原生 (cloud-native)、注重安全，并优化了开发者生产力 (developer productivity)。

正如 Janet 所发现的，最初的迁移努力会迅速带来回报。她的团队现在部署更频繁，问题更少，并且几乎不花时间维护他们的 CI/CD 基础设施。

问问自己： 上个月你的团队花了多少时间与 Jenkins 搏斗？如果把这些时间用于其他工作，你本可以构建出什么？

CI/CD 的未来已经到来。也许是时候让 Jenkins 成为过去式了。