Jenkins
定义
Jenkins 是一个开源软件项目，也是基于 Java 编写的自动化服务器，运行在 Servlet 容器中，为软件开发提供持续集成服务[6][1]。它可以连接软件配置管理工具，执行基于 Apache Ant、Apache Maven 的项目构建，也能运行任意的 Shell 脚本和 Windows 批处理命令，并支持通过多种方式触发构建[6]。
在结构上，Jenkins 由负责调度和协调的控制器(controller，旧称 master)与承担实际构建任务的代理节点(agent)组成，两者构成分布式构建体系[7][8]。项目以开源许可发布，可以部署在自有服务器或局域网环境内，不依赖外部托管服务[9]。
原理
Jenkins 的基本工作循环是：开发者把代码提交到版本库，Jenkins 通过 webhook、定时轮询或上游任务完成等触发条件发起一次构建，将源码取到工作区，再按预先配置的步骤执行构建与测试，最后把结果和报告反馈给相关人员[10]。构建产物可以归档，也可以打包后转送到目标服务器。
自 2.0 版本起，流水线(pipeline)成为核心功能，用一份名为 Jenkinsfile 的文本文件描述整条自动化流程，该文件使用基于 Apache Groovy 的领域特定语言编写，可与应用源码一起纳入版本控制[11][12]。流水线分为两种写法：声明式(declarative)以固定的 pipeline、agent、stages、steps 结构组织，可读性较好并由系统校验；脚本式(scripted)则是完整的 Groovy 程序，适合动态生成阶段和复杂逻辑[13]。
在声明式流水线中，agent 指令指定流水线或单个阶段的执行位置，可以是任意可用节点、带标签的节点、Docker 镜像或 Kubernetes Pod 模板；stages 与 steps 描述阶段划分和具体命令，environment 用于设置环境变量与凭据绑定，when 控制阶段执行条件，post 则定义无论成功或失败都要执行的通知与清理动作[14][10]。流水线状态会被记录，控制器重启后可以从断点继续运行而非丢失本次执行[15]。
插件是功能扩展的主要途径，连流水线本身的编排能力也由一组插件提供。常用的扩展包括版本控制与代码托管集成、构建工具调用、测试报告收集、静态代码扫描、容器镜像构建与部署等，团队也可以编写共享库，把多个仓库通用的流水线逻辑集中维护[16][17]。
发展历程
Jenkins 的前身是 Hudson，2004 年夏天由时任 Sun Microsystems 员工的川口耕介(Kohsuke Kawaguchi)作为个人项目发起，2005 年 2 月发布最初版本[3][18]。此后数年，它以优于 CruiseControl 等早期开源构建服务器的表现，逐渐成为持续集成领域使用较广的工具之一，并在 2008 年 5 月的 JavaOne 大会上获得开发者解决方案类别的杜克选择奖[12][19]。
2010 年 Sun 被 Oracle 收购后，Hudson 社区开始关注项目的治理与基础设施归属，双方围绕 Hudson 名称的商标权进行谈判，商标问题成为分歧的焦点[3][20]。2011 年 1 月 11 日，社区提出把项目名从 Hudson 改为 Jenkins；1 月 29 日投票结果公布，有效票中 214 票支持更名、14 票支持维持原名，Jenkins 项目由此成立[4][12]。2011 年 2 月 1 日，Oracle 表示将继续开发 Hudson，并把 Jenkins 视为分支，两个项目此后各自独立发展[12]。Hudson 后来被捐赠给 Eclipse 基金会，并于 2017 年 2 月被宣布为过时[21]。
2016 年 4 月 20 日，Jenkins 发布 2.0 版本，将流水线能力作为核心特性并默认启用，同时在初始安装时提供向导与推荐插件，改善开箱即用的体验[12][11]。2018 年 3 月，面向 Kubernetes 环境的 Jenkins X 项目对外公布[12]。
应用
在持续集成环节，Jenkins 从代码仓库拉取代码后自动执行构建与测试，集成 JUnit、Selenium 等框架在构建完成后运行单元测试、集成测试和功能测试，并阻止测试未通过的代码进入后续部署流程[16]。团队通常把代码提交、编译、测试、代码质量检查、镜像构建和部署等阶段组织成一条流水线，提交后自动触发，以便尽早发现集成冲突与接口不兼容等问题[22][16]。
在持续交付与部署环节，它可以把构建产物推送到测试、预发布和生产等不同环境，并借助插件与云资源对接，例如按需创建 EC2 实例或 Azure 虚拟机作为临时构建节点，空闲时自动回收[8]。常见场景还包括 Web 应用发布、微服务架构下多个服务的批量部署、移动应用构建发布，以及以代码方式管理基础设施[22]。由于可以完全运行在内网甚至隔离网络中，它在构建环境不能连外部云服务的组织里仍是常见选择[9]。
局限
Jenkins 需要使用者自行搭建和维护控制器、代理节点、插件与升级，基础设施的容量、补丁和可用性都由使用方负责，这与托管型持续集成服务有明显差别[9][23]。控制器是调度、界面、插件逻辑与元数据存储的集中点，构建规模上升后容易成为瓶颈，出现过长的构建队列和界面响应变慢，同时它也是单点故障，控制器不可用会阻塞整条交付流程[24]。
插件生态既是扩展能力所在，也带来维护负担：插件之间存在依赖链，升级时可能出现版本冲突或互不兼容，部分插件长期无人维护，插件自身的缺陷还可能影响整个控制器的稳定性。此外，Jenkins 及其插件的安全公告发布较为频繁，攻击面涉及网页界面、插件交互、代理通信和流水线代码执行，需要持续跟进更新与权限配置[25]。基于 Groovy 的脚本式流水线在逻辑复杂后会变得较难阅读和排查，界面与日志的可读性也常被认为是使用体验上的短板[25]。
参见
-
持续集成 —— Jenkins 最主要的使用场景，指频繁把代码合并到共享仓库并自动验证。
-
持续交付 —— 在持续集成基础上进一步自动化发布与部署流程。
-
Kubernetes —— 常被用作 Jenkins 代理节点的动态调度平台。
-
Docker —— 为流水线提供一致的构建环境并承载镜像构建与推送。
-
Hudson —— Jenkins 更名前的项目名称，2011 年后成为独立维护的分支。
参考资料
- 『Jenkins』Jenkins入门教程：从零到一的CI/CD实现 [引用日期2026-10-29]
- jenkins持续集成工具-产品介绍 [引用日期2026-10-29]
- Kohsuke Kawaguchi [引用日期2026-10-29]
- Jenkins! [引用日期2026-10-29]
- jenkins-ten-plugins [引用日期2026-10-29]
- google.com 上的网页 [引用日期2026-10-29]
- Best Practices [引用日期2026-10-29]
- Architecting for Scale [引用日期2026-10-29]
- cleansystemsconsulting.com 上的网页 [引用日期2026-10-29]
- Pipeline syntax [引用日期2026-10-29]
- Jenkins 2.0 is here! [引用日期2026-10-29]
- wikipedia.org 上的网页 [引用日期2026-10-29]
- Declarative vs Scripted Pipelines - Skip to main content [引用日期2026-10-29]
- Using a Jenkinsfile [引用日期2026-10-29]
- Pipeline and Jenkinsfile - Skip to main content [引用日期2026-10-29]
- Jenkins在持续集成与持续部署中的价值 [引用日期2026-10-29]
- der-praxischeck-pipeline-as-code-mit-jenkins-2 [引用日期2026-10-29]
- Hudson和Jenkins的恩恩怨怨 [引用日期2026-10-29]
- Jenkins详解-1 [引用日期2026-10-29]
- Hudson 社区提议将项目更名为 Jenkins [引用日期2026-10-29]