Jenkins入门介绍 - 什么是CI/CD？小白必看！
Jenkins入门介绍 — 什么是CI/CD？
欢迎来到Jenkins教程系列的第1篇！如果你是一名刚接触DevOps的新手，或者听说过"CI/CD""Jenkins"这些词但还不太理解，那么这篇文章就是为你准备的。我们将从零开始，用最通俗的语言带你理解Jenkins是什么、CI/CD是什么，以及为什么它们在现代软件开发中如此重要。
一、什么是Jenkins？
Jenkins是一个开源的、基于Java的自动化服务器，用于支持软件开发中的持续集成（CI）和持续交付/部署（CD）。简单来说，它就像一个"自动化机器人"，可以帮你把代码从编写到上线的整个过程自动化起来。
Jenkins的历史可以追溯到2004年。当时，Sun Microsystems的工程师Kohsuke Kawaguchi（中文社区常称他为"KK"）为了简化自己的日常工作，开发了一个名为Hudson的项目。Hudson很快在开发者社区中流行起来，成为最流行的CI工具之一。然而在2011年，由于与Oracle（收购了Sun Microsystems）在项目治理上的分歧，社区决定将项目fork（分叉），新项目命名为Jenkins。从此，Jenkins和Hudson走上了不同的发展道路，而Jenkins凭借活跃的社区和丰富的插件生态，逐渐成为了CI/CD领域的绝对主流。
如今的Jenkins拥有以下特点：
- 完全免费开源：基于MIT许可证，任何人都可以免费使用和修改
- 跨平台：支持Windows、Linux、macOS等主流操作系统
- 插件生态极其丰富：拥有1800+插件，几乎可以和所有主流工具集成
- 社区活跃：全球数百万开发者在使用和贡献Jenkins
- 高度可扩展：通过插件和Pipeline可以定制几乎任何自动化流程
二、什么是CI/CD？
理解Jenkins之前，我们必须先搞清楚CI/CD这个概念。CI/CD是现代软件开发的核心理念，也是Jenkins存在的意义。让我们逐一拆解。
2.1 持续集成（Continuous Integration，CI）
想象一下这样的场景：一个团队有5个开发者，每个人都在自己的电脑上写代码，写了整整一周才合并到一起。结果合并的时候发现冲突满天飞，代码根本跑不起来，光是解决冲突就又花了好几天。这种痛苦，做过开发的人都懂。
持续集成就是为了解决这个问题的。它的核心理念是：频繁地将代码合并到主分支，并且每次合并都自动运行构建和测试。
具体来说，CI要求开发者：
- 每天至少向主分支提交一次代码
- 每次提交都触发自动化的构建过程
- 每次构建都运行自动化的测试用例
- 如果构建或测试失败，立即修复，不允许新的代码合并进来
打个比方：CI就像是一个"质检站"，每当有新的零件（代码）送到生产线上，质检站就立即检查这个零件是否合格，而不是等到整辆车组装完了才发现零件有问题。
2.2 持续交付（Continuous Delivery，CD）
持续集成保证了代码的质量，那接下来呢？代码通过了测试，我们还需要把它部署到服务器上，让用户能够使用。持续交付就是CI的下一步延伸。
持续交付的意思是：代码在通过自动化测试之后，自动地准备好可以随时部署到生产环境的状态。注意，这里说的是"准备好"，但最终是否真的部署到生产环境，还需要人工点击一个按钮来确认。
用一个生活中的例子来理解：持续交付就像是一家餐厅的厨房，厨师把菜做好、摆好盘、放在出餐口，但需要服务员确认"这桌客人可以上菜了"才会真正端出去。
2.3 持续部署（Continuous Deployment，CD）
注意，这里缩写也是CD，但含义不同。持续部署比持续交付更进一步：代码通过所有测试后，自动部署到生产环境，完全不需要人工干预。
还是用餐厅的比喻：持续部署就是自动售货机——你选好商品付了钱，商品直接就出来了，不需要任何服务员操作。
持续部署听起来很美好，但它对自动化测试的覆盖率要求非常高。如果你的测试不够充分，自动部署就可能导致有问题的代码直接上线，影响用户体验。因此，很多团队选择"持续交付"（人工把关最后一步）而非"持续部署"（全自动上线）。
2.4 CI/CD全流程一览
让我们把CI/CD的完整流程串起来：
开发者提交代码
↓
自动拉取最新代码（CI）
↓
自动编译/构建（CI）
↓
自动运行单元测试（CI）
↓
自动运行集成测试（CI）
↓
自动打包（如Docker镜像）（CD）
↓
自动部署到测试环境（CD）
↓
人工确认 / 自动部署到生产环境（持续交付 vs 持续部署）整个流程中的每一步都可以由Jenkins来自动化完成，这就是Jenkins的核心价值。
三、为什么需要Jenkins？— 手动构建 vs 自动构建
也许你会问：我不用Jenkins，手动做这些事情不行吗？让我们来对比一下。
3.1 手动构建的痛苦
在没有Jenkins的时代，一次典型的发布流程是这样的：
- 第1步：开发者手动从Git仓库拉取最新代码
- 第2步：在本地编译打包
mvn clean package - 第3步：手动运行测试（或者干脆跳过测试，因为太慢了）
- 第4步：把打包好的文件用SCP上传到服务器
- 第5步：SSH登录服务器，停掉旧服务，替换文件，启动新服务
- 第6步：手动检查服务是否正常运行
这个过程存在严重的问题：
- 耗时：每次发布至少需要30分钟到1小时，甚至更久
- 容易出错：手动操作难免遗漏步骤或输错命令
- 不可重复：不同人操作的方式可能不同，结果不一致
- 无法追溯：出了问题很难回溯是哪一步出了差错
- 影响开发效率：开发者把大量时间浪费在部署上，而不是写代码
3.2 自动构建的优雅
使用Jenkins后，同样的流程变成了这样：
- 开发者只需提交代码到Git
- Jenkins自动检测到代码变更
- Jenkins自动拉取、编译、测试、打包、部署
- 开发者收到构建结果通知（成功或失败）
对比效果：
手动构建：
- 耗时：30分钟 ~ 数小时
- 出错率：高
- 可追溯性：差
- 频率：一周一次甚至更少
- 人的参与：全程手动
自动构建（Jenkins）：
- 耗时：几分钟（自动化执行）
- 出错率：极低
- 可追溯性：完整记录每次构建的日志
- 频率：每天多次
- 人的参与：只需提交代码，其余全自动这就是为什么Jenkins（以及CI/CD）已经成为现代软件开发的标配。它不仅节省时间，更重要的是提高了软件交付的质量和可靠性。
四、Jenkins能做什么？— 常见使用场景
Jenkins的功能远不止"编译和部署"，它几乎可以自动化任何重复性的软件工程任务。以下是常见的使用场景：
4.1 自动化构建与测试
这是最基础也是最核心的场景。每当开发者提交代码，Jenkins自动执行：
- 拉取最新代码
- 编译代码（支持Maven、Gradle、npm、pip等各种构建工具）
- 运行单元测试和集成测试
- 生成测试报告
4.2 持续部署
Jenkins可以将构建产物自动部署到各种环境：
- 部署到测试环境，供QA团队测试
- 部署到预发布环境（Staging），模拟生产环境验证
- 部署到生产环境（通常需要人工审批）
支持的部署方式包括SSH、Docker、Kubernetes、云平台（AWS、阿里云等）等。
4.3 代码质量检查
在构建过程中，Jenkins可以集成各种代码质量工具：
- SonarQube：代码静态分析，检测代码异味、漏洞和重复代码
- Checkstyle / ESLint：代码风格检查
- FindBugs / PMD：Bug模式检测
- Cobertura / JaCoCo：测试覆盖率统计
4.4 定时任务
Jenkins可以执行定时调度任务，例如：
- 每天凌晨自动运行全量回归测试
- 每周自动生成项目健康度报告
- 定时清理过期的构建产物和Docker镜像
- 定时从外部数据源同步数据
4.5 多环境流水线
通过Jenkins Pipeline，可以定义一条从开发到生产的完整流水线：
开发环境构建 → 单元测试 → 代码扫描 → 集成测试
→ 构建Docker镜像 → 推送镜像仓库 → 部署到测试环境
→ 自动化验收测试 → 人工审批 → 部署到生产环境每一步的执行条件、超时时间、失败处理策略都可以精细控制。
4.6 自动化通知与协作
Jenkins可以在构建完成后自动发送通知：
- 邮件通知：构建成功/失败时发送邮件
- Slack/钉钉/企业微信通知：推送到团队聊天频道
- Webhook通知：触发其他系统的后续流程
4.7 基础设施自动化
Jenkins不仅用于应用部署，还可以管理基础设施：
- 配合Terraform自动创建/销毁云资源
- 配合Ansible自动配置服务器环境
- 自动管理Kubernetes集群
五、Jenkins的核心概念
在学习使用Jenkins之前，你需要理解以下几个核心概念。这些概念贯穿Jenkins的方方面面，理解它们是掌握Jenkins的基础。
5.1 Job（任务/项目）
Job是Jenkins中最基本的执行单元。你可以把Job理解为"一个要做的事情"。比如，"构建my-app项目"是一个Job，"运行自动化测试"也是一个Job。
Jenkins中有多种类型的Job：
- Freestyle Project：自由风格项目，通过图形界面配置，适合简单任务
- Pipeline：流水线项目，通过代码（Jenkinsfile）定义流程，是最推荐的方式
- Multi-configuration Project：多配置项目，可以在不同环境下执行同一任务
- Folder：文件夹，用于组织和管理多个Job
5.2 Build（构建）
Build是Job的一次具体执行。每次你触发一个Job，就会产生一个Build。Build有以下重要属性：
- Build Number：构建编号，从1开始递增，用于唯一标识每次构建
- Build Status：构建状态，包括成功（蓝色）、失败（红色）、不稳定（黄色）、中止（灰色）
- Build Log：构建日志，记录了构建过程中的所有输出信息
- Build Artifacts：构建产物，如编译后的jar包、Docker镜像等
举个例子：你有一个名为"build-my-app"的Job，第1次运行产生了Build #1，第2次运行产生了Build #2，以此类推。每次Build都有完整的日志和产物，方便你追溯和排查问题。
5.3 Pipeline（流水线）
Pipeline是Jenkins最重要的概念之一，也是现代Jenkins使用方式的推荐选择。Pipeline允许你用代码来定义整个构建/部署流程，而不是通过图形界面一步步点击配置。
Pipeline的定义写在Jenkinsfile中，和源代码一起存放在Git仓库中，实现了"构建即代码（Pipeline as Code）"的理念。
一个简单的Pipeline示例：
pipeline {
agent any
stages {
stage('构建') {
steps {
sh 'mvn clean package'
}
}
stage('测试') {
steps {
sh 'mvn test'
}
}
stage('部署') {
steps {
sh './deploy.sh'
}
}
}
}Pipeline的核心组成：
- Stage（阶段）：流水线中的一个逻辑步骤，如"构建""测试""部署"
- Step（步骤）：Stage中的具体操作，如执行一条Shell命令
- Agent（代理）：定义Pipeline在哪里执行
- Post（后置处理）：流水线完成后的操作，如发送通知
5.4 Node（节点）
Node是Jenkins中执行Build的机器。Jenkins支持分布式构建，即可以在多台机器上同时运行任务。
Node分为两种：
- Master节点：Jenkins的主服务器，负责调度任务、提供Web界面。Master节点本身也可以执行Build，但通常建议让Master专注于调度
- Agent节点（也称为Slave节点）：专门用来执行Build的工作机器。你可以添加多个Agent节点来提高并行构建能力
举个例子：你的Jenkins Master部署在一台服务器上，但你同时配置了3台Agent机器——一台用来跑Java项目的构建，一台用来跑前端项目的构建，一台用来做性能测试。这样多个任务可以并行执行，大大提高了效率。
5.5 Workspace（工作空间）
Workspace是Node上的一个目录，Jenkins在这里检出代码、执行构建。每个Job在每次Build时都会有一个对应的Workspace。
Workspace的典型目录结构如下：
/var/lib/jenkins/workspace/
├── my-app/ # Job "my-app"的工作空间
│ ├── src/ # 源代码
│ ├── pom.xml # 构建配置
│ └── target/ # 构建产物
├── frontend-build/ # Job "frontend-build"的工作空间
│ ├── package.json
│ └── dist/
└── api-test/ # Job "api-test"的工作空间
├── tests/
└── reports/理解Workspace很重要，因为：
- 不同的Job的Workspace是相互隔离的，不会互相干扰
- 同一Job的多次Build默认复用同一个Workspace，这意味着上次构建的残留文件可能影响下次构建（需要注意清理）
- Workspace的大小会随着构建次数增长，需要定期清理以避免磁盘空间不足
六、Jenkins生态系统
Jenkins的强大不仅在于其核心功能，更在于其繁荣的生态系统。这个生态系统让Jenkins几乎可以与任何工具集成，满足各种定制化需求。
6.1 插件（Plugins）
插件是Jenkins生态系统的核心。截至2026年，Jenkins插件仓库中已有1800+个插件，涵盖了软件开发生命周期的方方面面。以下是一些最常用的插件分类：
版本控制插件：
- Git Plugin：与Git仓库集成
- GitHub Plugin：与GitHub深度集成，支持PR触发构建
- GitLab Plugin：与GitLab集成
- SVN Plugin：与Subversion集成
构建工具插件：
- Maven Project Plugin：Maven项目支持
- Gradle Plugin：Gradle构建支持
- NodeJS Plugin：Node.js环境支持
部署与容器插件：
- Docker Plugin：Docker容器管理
- Kubernetes Plugin：K8s集群部署
- AWS / Azure / 阿里云插件：云平台集成
通知与协作插件：
- Email Extension Plugin：增强的邮件通知
- Slack Plugin：Slack消息推送
- DingTalk Plugin：钉钉机器人通知
代码质量插件：
- SonarQube Plugin：代码质量分析
- JaCoCo Plugin：测试覆盖率
- Warnings Next Generation Plugin：编译警告收集
安装插件非常简单：进入Jenkins管理界面 → 插件管理 → 可选插件，搜索并安装即可。安装后大多数插件不需要重启Jenkins就能生效。
6.2 Jenkins社区
Jenkins拥有一个全球性的活跃社区，这是它能够持续发展的重要原因：
- Jenkins官方文档：https://www.jenkins.io/doc/ — 最权威的参考资料
- Jenkins中文社区：由国内开发者维护的中文文档和交流平台
- Jenkins GitHub仓库：https://github.com/jenkinsci/jenkins — 源代码和Issue追踪
- Jenkins邮件列表和论坛：全球开发者的讨论和互助平台
- Jenkins世界大会（DevOps World）：年度技术大会，汇聚全球Jenkins用户和贡献者
6.3 相关工具对比
在CI/CD领域，Jenkins并不是唯一的选择。以下是常见的CI/CD工具对比：
工具 | 开源 | 特点 | 适合场景
-------------|------|------------------------------|----------
Jenkins | 是 | 插件丰富、高度灵活、社区活跃 | 任何规模、复杂流水线
GitLab CI | 是 | 与GitLab深度集成、YAML配置 | 使用GitLab的团队
GitHub Actions| 否 | 与GitHub深度集成、云端执行 | 开源项目、GitHub用户
CircleCI | 否 | 云端服务、配置简单、执行速度快 | 中小团队、快速起步
Travis CI | 否 | 云端服务、开源项目免费 | 开源项目
Tekton | 是 | 云原生、基于Kubernetes | K8s原生环境
Drone | 是 | 轻量级、Docker原生、配置简单 | 容器化项目Jenkins的最大优势在于灵活性和插件生态。无论你使用什么技术栈、部署到什么环境，几乎都能找到对应的Jenkins插件。而其他工具通常在特定场景下更方便，但灵活性不如Jenkins。
七、总结
在这篇文章中，我们全面了解了Jenkins的基础知识：
- Jenkins是一个开源的自动化服务器，用于实现CI/CD
- CI（持续集成）要求频繁合并代码并自动构建测试
- CD（持续交付）确保代码随时可以部署到生产环境
- CD（持续部署）更进一步，全自动部署到生产环境
- Jenkins通过自动化解决了手动构建的效率低、易出错、难追溯等问题
- Jenkins的核心概念包括Job、Build、Pipeline、Node和Workspace
- Jenkins拥有1800+插件和活跃的全球社区，生态系统极其繁荣
在下一篇教程中，我们将手把手教你安装和配置Jenkins，让你在自己的环境中运行起第一个Jenkins实例。敬请期待！
