Jenkins持续集成CI与持续部署CD过程说明
Jenkins 是一个开源自动化服务器,广泛用于持续集成(Continuous Integration, CI)和持续部署(Continuous Deployment, CD)。通过使用 Jenkins,开发团队可以自动化构建、测试和部署应用程序,从而加快软件开发周期,提高软件质量。
1 持续集成(Continuous Integration)
持续集成是一种软件开发实践,其中团队频繁地将代码更改合并到共享存储库中。每次代码更改后,自动构建和测试过程运行,以确保这些更改不会破坏整个应用程序。
1.1 安装 Jenkins:
在服务器上安装 Jenkins。你可以从 Jenkins官网 下载安装包或使用包管理器(如 apt, yum)进行安装。

1.2 配置 Jenkins:
安装完成后,访问 Jenkins 的 Web 界面(通常是 http://<your-server>:8080),并根据提示完成初始设置。

1.3 创建 Jenkins 项目:
在 Jenkins 仪表盘上,点击“新建”来创建一个新的项目。
选择合适的项目类型(例如,自由风格项目或使用流水线项目)。

1.4 配置源代码管理:
指定你的代码仓库(如 Git),并输入仓库的 URL。

1.5 配置构建触发器:
设置构建触发器,例如轮询 SCM(定期检查 SCM 的更改),或使用 Webhook 来实时触发构建。

1.6 添加构建步骤:
这是Jenkins设置的最重要的步骤,配置构建脚本(如 Maven、Gradle 或 shell 脚本),用于编译和构建你的应用程序。

1.7 添加测试步骤:
配置测试脚本,例如使用 JUnit 或 TestNG 进行单元测试和集成测试。
1.8 配置构建后操作:
配置构建后操作,如将构建结果归档、发送通知等。
2 持续部署(Continuous Deployment)
持续部署是一种扩展了持续集成的实践,其中每次成功的代码更改都会自动部署到生产环境或其他目标环境。
2.1 配置部署环境:
在 Jenkins 中配置部署环境,例如使用 SSH、Docker 或 Kubernetes 等技术将应用程序部署到目标服务器或容器中。
2.2 添加部署步骤:
在 Jenkins 的构建配置中添加部署脚本或使用 Jenkins 插件(如 Publish Over SSH, Kubernetes Plugin 等)来自动化部署过程。
2.3 配置环境变量和凭据:
确保 Jenkins 有权访问部署目标,并正确配置任何必要的环境变量和凭据(如 SSH 密钥、Docker 镜像仓库凭据等)。
2.4 使用蓝绿部署或金丝雀发布:
为了减少风险,可以使用蓝绿部署或金丝雀发布策略,在生产环境中逐步引入新版本的应用程序。
2.5 监控和回滚:
设置监控来跟踪部署后的应用程序性能,并准备好在出现问题时快速回滚到先前的稳定版本。
3 示例:使用 Jenkins Pipeline 实现 CI/CD
Jenkins Pipeline 提供了一种声明式和脚本式的方式来定义项目的自动化流程。以下是一个简单的 Jenkinsfile 示例,用于实现 CI/CD:
1 | |
这个示例中,我们定义了四个阶段:检出代码、构建、测试和部署。通过这种方式,可以轻松地实现持续集成和持续部署的自动化。
4、stages与steps的区别
在 Jenkins 的 Pipeline as Code(通常使用 Jenkinsfile 编写)中,stages 和 steps 是构建流程中两个不同层级的概念,它们的区别主要体现在 逻辑分组 和 执行粒度 上。以下是详细对比:
1. 核心区别
| 概念 | 作用 | 层级 | 典型内容 |
|---|---|---|---|
| stages | 将整个构建流程 逻辑分组 为多个阶段(如构建、测试、部署),每个阶段有明确的职责和目标。 | 高层级(宏观) | 包含多个 steps,代表一个完整的、独立的构建环节(例如 “Build” 阶段包含编译代码的步骤)。 |
| steps | 定义 具体执行的操作(如运行 shell 命令、调用插件、执行脚本等),是实际执行的代码单元。 | 低层级(微观) | 包含具体的指令(例如 sh 'mvn clean package' 或 echo 'Hello')。 |
2. 结构关系
Jenkins Pipeline 的典型结构是 **stages 包含多个 stage,每个 stage 包含一个或多个 steps**:
1 | |
3. 详细说明
(1) stages(阶段)
作用:将构建流程划分为逻辑上独立的阶段,每个阶段代表一个完整的任务单元(如编译、测试、部署)。
特点:
- 可视化:在 Jenkins 的 Blue Ocean 或经典 UI 中,
stages会以 独立的卡片/块 形式展示,便于区分不同阶段的执行状态(成功/失败)。 - 并行/顺序控制:通过
parallel或stage的顺序排列,控制阶段的执行逻辑(例如并行测试多个模块)。 - 必选结构:在声明式 Pipeline(
pipeline { ... })中,stages是 必需的顶级块(除非使用脚本式 Pipeline)。
- 可视化:在 Jenkins 的 Blue Ocean 或经典 UI 中,
常见阶段示例:
Build:编译代码(如 Maven/Gradle/NPM)。Test:运行单元测试、集成测试。Deploy:部署到测试环境/生产环境。Notify:发送通知(如邮件、Slack)。
(2) steps(步骤)
作用:定义每个阶段内 具体执行的操作,是实际运行的代码指令。
特点:
- 原子性:每个
step是一个独立的操作(如执行一条 shell 命令、调用一个 Jenkins 插件功能)。 - 灵活性:支持多种类型的步骤(Shell 命令、Groovy 脚本、插件提供的专用步骤等)。
- 必选内容:每个
stage必须包含至少一个steps块(即使只有一个步骤)。
- 原子性:每个
常见步骤示例:
sh 'command':在 Linux/macOS 上执行 Shell 命令。bat 'command':在 Windows 上执行批处理命令。echo 'message':打印日志信息。checkout scm:拉取代码仓库的最新代码。- 插件步骤:如
docker.build('image:tag')(Docker 插件)、npm('install')(NodeJS 插件)。
4. 对比示例
场景:构建一个 Java 应用并部署
声明式 Pipeline(推荐)
1 | |
- 说明:
stages划分为 4 个逻辑阶段(拉取代码、构建、测试、部署)。- 每个
stage包含 1~2 个steps(具体操作)。
脚本式 Pipeline(灵活但复杂)
1 | |
- 说明:
- 脚本式 Pipeline 没有显式的
stages块,但通过stage('名称') { ... }隐式分组,内部的代码默认属于steps。
- 脚本式 Pipeline 没有显式的
5. 关键总结
| 问题 | 答案 |
|---|---|
| stages 是什么? | 将构建流程分为多个逻辑阶段(如构建、测试、部署),每个阶段有明确目标。 |
| steps 是什么? | 阶段内具体执行的操作(如运行命令、调用插件),是实际执行的代码单元。 |
| 为什么需要 stages? | 提高可读性、可视化执行状态、支持阶段级控制(如并行、失败暂停)。 |
| steps 可以单独存在吗? | 在脚本式 Pipeline 中可以隐式存在(通过 stage 块),但声明式 Pipeline 必须显式包含在 stages 中。 |
| 常见步骤类型 | Shell 命令(sh/bat)、日志输出(echo)、插件步骤(如 Docker/NPM 操作)。 |
6. 最佳实践
- 合理划分 stages:
- 按职责分离(如构建、测试、部署分开),便于定位问题。
- 每个 stage 包含明确的 steps:
- 避免在一个
stage中塞入过多无关操作。
- 避免在一个
- 利用声明式 Pipeline:
- 结构清晰,易于维护,适合大多数场景。
- 调试 steps:
- 通过
echo或script { ... }块输出调试信息(例如echo "当前目录: ${pwd()}")。
- 通过
通过理解 stages 和 steps 的区别,可以更高效地设计和维护 Jenkins Pipeline,确保构建流程的可读性和可维护性。