jenkins

type

status

date

slug

summary

CI/CD简介

CI/CD是实现敏捷开发和Devops理念的一种方法，具体而言，CI/CD 可让持续自动化和持续监控贯穿于应用的整个生命周期，从集成和测试，到交付和部署。这些关联的事务通常被统称为CI/CD 管道（Pipeline），由开发（RD）、测试（QA）、运维（OP）团队以敏捷方式协同支持。

CI/CD 是持续集成（Continuous Integration，CI）、持续交付（Continuous Delivery，CD）与持续部署（Continuous Deployment，CD）的简称，注意CD对应了两个名词。

持续集成

持续集成（Continuous Integration，简称 CI）是一种软件开发实践，指开发团队频繁地将代码更改合并到主干代码库中，每次集成都通过自动化构建和测试来验证代码的正确性。持续集成的目标是快速发现并解决代码冲突和错误，确保代码始终保持可用状态，从而提高开发效率和软件质量。典型的持续集成流程包括：代码提交、自动构建（编译和打包）、自动化测试，以及生成报告。常用工具包括 Jenkins、GitLab CI/CD、CircleCI 等。持续集成：持续集成是指多名开发者在开发不同功能代码的过程当中，可以频繁的将代码行合并到一起并切相互不影响工作。

持续交付

完成以上CI的流程后，持续交付可自动将已验证的代码发布到存储代码库。为了实现高效的持续交付流程，务必要确保 CI 已内置于开发管道。持续交付的目标是拥有一个可随时部署到生产环境的代码库。在持续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）都涉及测试自动化和代码发布自动化。在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中。注意，持续交付在自动化测试和集成结束后，具备部署的能力，但不会自动部署，而是手动部署。如果有自动部署，则是持续部署的概念了

持续部署

对于一个成熟的 CI/CD 管道来说，最后的阶段是持续部署。作为持续交付——自动将生产就绪型构建版本发布到代码存储库的延伸，持续部署可以自动将应用发布到生产环境。由于在生产之前的管道阶段没有手动门控，因此持续部署在很大程度上都得依赖精心设计的自动化测试实际上，持续部署意味着开发人员对应用的更改在编写后的几分钟内就能生效（假设它通过了自动化测试）。这更加便于持续接收和整合用户反馈。总而言之，所有这些 CI/CD 的关联步骤都有助于降低应用的部署风险，因此更便于以小件的方式（而非一次性）发布对应用的更改。不过，由于还需要编写自动化测试以适应 CI/CD 管道中的各种测试和发布阶段

在 CI/CD 流程中，整个过程可以划分为多个阶段，每个阶段又包含多个具体的步骤。阶段用于清晰地标识流程中的关键节点，比如代码构建、单元测试、集成测试和部署等，而步骤则是具体执行的操作，比如参数传递、程序调用等。通过这种分层设计，我们可以更加清晰地了解整个流程的结构和进展。所以即便是我们手动操作也需要规划阶段、步骤，结合起来我们叫做流程，也就流水线。然而，如果完全依靠手动执行，不仅效率低下，还容易出错。为了实现流程的高效管理和自动化，我们需要借助工具，比如专门的 CI/CD Server——<a href="http://jenkins-ci.org">Jenkins</a>

Jenkins是一款采用JAVA编写的开源持续集成（Continuous Integration）工具，常用于自动化各种CI、CD任务，能够实现自动化集成发布。jenkins的基本能力只是一个CICD Server，其功能主要通过插件（Plugin）进行扩展，通过插件 Jenkins 能够轻松适配不同的场景和需求。所以在使用jenksin的时候需要安装大量的插件。比如需要与 Docker 集成，就需要安装 Docker 插件；如果需要支持 Kubernetes，则需要 Kubernetes 插件。这种插件化设计极大地增强了 Jenkins 的灵活性和扩展性，使其能够适配多种复杂的开发、测试和部署场景。

二进制部署

JDK 部署

Jenkins使用Java语言开发的，部署Jenkins时需要先安装JDK。Jenkins自2.357及2.361.1 LTS版本起，同时支持Java 11和Java 17。JDK的两种安装方式：源码安装和yum安装

1、源码安装这里我下载的是.tar.gz格式的文件，jdk版本为11 官网下载页面：<a href="https://www.oracle.com/java/technologies/downloads/#java11">jdk11</a>

解压jdk安装包文件

将jdk的解压文件移动到此目录下

在环境变量中配置jdk

加载环境变量让配置生效

检验jdk是否安装成功

2、yum安装jdk，安装目录为/usr/lib/jvm

验证

Jenkins部署

官网下载页面：<a href="https://get.jenkins.io/redhat/">https://get.jenkins.io/redhat/</a> 从 <a href="https://mirrors.tuna.tsinghua.edu.cn/jenkins/redhat-stable/">清华的镜像站点</a>下载 Jenkins 包

修改jenkins配置文件，修改内容如下

如果你像我一样，也更改了家目录，那么需要单独创建并调整权限

启动jenkins

浏览器访问jenkins页面地址

查看密码，将密码粘贴至页面，点击继续

因为Jenkins插件需要连接默认官网下载，速度非常慢，而且经过会失败，可以暂时先跳过插件安装，我这里选择的是安装推荐的插件

如果选择的是选择插件来安装，则执行下图

最后，添加一个管理员账户，并进入Jenkins后台

卸载

卸载yum方式安装的jenkins默认安装主目录是在/var/lib/jenkins，停止jenkins服务

卸载jenkins

彻底删除残留文件

用户管理

创建用户

点击设置，找到安全列表选择管理用户

创建用户，点击 Create User 创建一个 test 用户

使用新创建的 test 用户进行登录，测试是否可以登录

基于角色的权限管理

当我们安装好Jenkins之后，默认的授权策略是登录的用户可以做任何事情，对于安全方面这样存在挑战。Jenkins有一个好用的权限管理插件Role-based Authorization Strategy。这个插件在大规模使用上还是比较稳定的，所以推荐大家使用。进入插件管理，搜索Role-based Authorization Strategy, 我们来安装此插件。安装插件后最好重启一下Jenkins

在系统管理→全局安全配置修改授权策略为Role-based Strategy，然后点击保存

此时用 test 用户登录发现没有任何权限

使用管理员账户为用户分配角色，点击系统管理 → Manage and Assign Roles（管理和分配角色）。我们可以创建全局角色、项目角色和节点角色全局角色：管理员等高级用户可以创建基于全局的角色，例如给所有用户绑定最基本的 Jenkins 访问权限。项目角色：针对某个或某些项目的角色，可以限制用户只能操作特定项目。节点角色：与节点相关的权限

Global Roles

在 Jenkins 里，如果你安装了 Role-Based Strategy 插件，就可以分配不同的权限给不同的用户或用户组。其中的 Global Roles（全局角色），作用范围是整个 Jenkins 实例，不针对某个具体项目。一旦你在 Global Roles 给了某个用户某项权限（比如 Job Read），那这个用户在所有项目中都能拥有这个权限。哪怕你在下面的 Item Roles 中限制了他，他依然能看到所有作业——因为全局已经给他开了口子。

对于管理员admin具有所有权限，新创建一个全局角色test-global具有对作业读取权限

Item Roles

我们可以使用正则表达式管理 Jenkins 项目权限，比如我们有多个流水线项目名都以 test- 开头：test-pipeline-service、test-pipeline-web等。让开发团队A角色只能访问这些以 test- 开头的作业，而不是访问 Jenkins 上的所有项目。首先定位到 item Roles，然后填写 Role to add 字段的值为 test2-item 意思是这个角色的名称，Pattern填写要匹配的项目test2.*，表示匹配所有以 test2 开头的作业，我们点击Add添加权限。

Node Roles

Jenkins 中的代理节点（Agent）权限，也可以按照 Item Roles 中使用正则表达式来配置，就像项目权限一样。不过在实际使用中，我们通常不会单独为代理节点配置访问权限。在流水线中，一般会通过 agent 标签指定使用哪个节点，因此权限是间接受控的。大多数用户对代理节点没有直接操作的需求，所以默认权限配置就够用了

当然，如果你有特殊需求，比如需要限制某些用户只能使用指定的节点（GPU 资源节点），或者希望某些用户能查看/管理某些 Agent 的配置。那么也可以为代理节点设置权限规则

给用户分配角色

创建好了每个角色对应的权限，后续我们会根据不同的用户给予不同的角色权限。点击系统管理 → Manage and Assign Roles（管理和分配角色）

进入 Manage and Assign Roles，点击Assign Roles，为用户绑定相应的角色： test1 用户：分别绑定 test-global 和 test1-item test2 用户：分别绑定 test-global 和 test2-item

保存配置，然后分别使用test1用户和test2用户登录系统。使用 test1 用户登录进入系统后，只能对当前项目组的项目进行构建

使用 test2 用户登录进入系统后，只能对当前项目组的项目进行构建

安全矩阵

点击系统管理 → 全局安全配置，授权策略选择安全矩阵

然后点击 Add user or group，添加 test 用户只有read权限，和任务的read权限。设置后点击保存。使用test用户登录jenkins，test用户只有只读权限，不能构建

在 Jenkins 中使用项目矩阵授权策略时，可以为每个项目分别设置权限，这虽然很灵活，但当项目数量变多时，问题也随之而来，每创建一个新项目，就必须手动为它单独配置权限，工作量非常大；无法一键对一类项目，比如所有以 test- 开头的项目统一设置权限；不能批量管理，维护起来很麻烦，容易出错

为了解决这些问题，Jenkins 提供了一种更高效的权限管理方式：基于角色的权限控制（Role-Based Authorization Strategy），这种方式可以：创建不同角色，比如开发、测试、管理员给每个角色分配不同权限使用正则表达式批量匹配一类项目（如 ^test-.*），一次设置多个项目权限管理权限更清晰、更统一，适合企业级使用

项目

一个典型的CICD操作过程可以抽象为Pipeline形式，这种类型的Pipeline一般由构建、测试和打包等几个典型阶段组成，每个阶段的具体操作过程都可能需要特定工具程序的参与。例如maven工程项目多半要依赖maven和jdk环境，而node.js项目则要用到npm工具等，这些工具需要事先经由系统管理→全局工具配置进行配置，或者于Jenkins Host上部署上相关的应用程序

通常，一个典型的 CI/CD 过程会涉及输入和输出两个主要部分。输入通常是指从代码仓库GitLab中获取源代码，并将其克隆到 Jenkins 所在的节点。输出是指将生成的构建结果进行打包，并转换为特定的格式，如 JAR、EXE、ELF、Docker 镜像等。甚至还要推送到目标工件库中（例如DockerHub）以便于存储和分发。若需要事先完成认证才能访问代码仓库服务及工件库服务时，Jenkins支持将这些认证凭据以安全方式事先定义，并在Pipeline自动化执行时自动引用

Jenkins 拥有功能强大的 Web UI，尤其是在 1.x 时代，用户可以通过图形界面创建自由风格的任务（freestyle job）以及配置流水线。这种方式直观易用，但也存在明显的局限性：配置高度依赖图形界面，难以进行移植和复用，尤其在多项目、跨团队协作或需要版本控制的场景中，显得力不从心。为了解决这些问题，Jenkins 从 2.x 版本开始引入了对流水线即代码（Pipeline as Code） 的支持，允许使用纯文本文件来定义流水线逻辑。这个用于保存流水线代码的文件被称为 Jenkinsfile。它本质上是一个可读、可维护的文本文件，通常与项目代码一起保存在版本控制系统（如 Git）中。这样不仅提升了配置的可追溯性和复用性，也为团队协作提供了便利。

在 Jenkins 2.x 中，流水线可以通过两种方式创建：一是直接在 Jenkins Web UI 中配置 pipeline 类型的任务，二是通过项目代码仓库中的 Jenkinsfile 自动加载定义的流水线逻辑。后者是更推荐的方式，因为它实现了代码与构建流程的绑定，符合基础设施即代码（Infrastructure as Code）的理念。值得一提的是，Jenkins 2.x 保持了对 1.x 配置方式的兼容性，允许用户在不完全放弃旧工作流的前提下，逐步迁移到新的 Jenkinsfile 架构。这种向后兼容的设计，使 Jenkins 2.x 既保留了传统用户的使用习惯，又满足了现代 DevOps 实践对自动化、版本控制和可维护性的需求，成为一款强大且灵活的 CI/CD 工具。

无论是哪个版本的Jenkins，都要通过新建一个指定类型的项目来添加一个新的Job。所谓的项目类型主要是用于分类一个具体的CI任务在其构建定义上的区别，比如对于自由风格类型项目的构建部分来说，典型的特征之一便是对shell脚本及Windows批处理脚本的支持。为便于用户定义CICD的具体步骤，Jenkins为特地提供了不同类型的Job，例如自由风格的作业、Pipeline作业、Maven工程作业、多配置项目、多分支流水线等

自由风格项目

自由风格的流水线跟自己编写shell脚本执行其实没太大的区别，需要宿主机节点也安装对应的工具，比如Maven工程项目多半要依赖maven和jdk环境，而node.js项目则要用到npm工具等。这种类型的pipeline一般由构建、测试、打包等几个典型的阶段组成，每个阶段的具体操作过程都可能需要特定的工具程序参与。

自由风格类型项目，指在提供一种相对开放的项目构建途径，来完成各类任务，是大多数Jenkins任务的传统选择。接下来我们输入项目的名称freestyle-job，选中构建一个自由风格的项目。

我们这里只是为了测试演示，简单执行一条shell命令，并克隆一个项目代码

在创建的自由风格的项目上，通过 立即构建 即可立即触发流水线的执行。任务执行结束后，即可通过其 构建号 相应的控制台输出了解构建状态。查看输出，当执行时会自动创建workspace目录

登录jenkins服务器，就能看到创建的workspace目录及克隆下来的代码

自由风格流水线无法做到幂等，每次执行前需要先清理workspace目录，比如我们再次执行会提示目录已经存在

编辑jenkins配置，勾选 Delete workspace before build starts ，点击保存，然后再次执行即可

流水线项目

在日常阅读 Jenkins 相关资料的过程中，我发现不少文章只是将官方文档中的内容直接搬运过来，缺乏实际理解和消化。读者很难判断这些作者是否真正掌握了其中的知识点。而以我个人的学习经验来说，哪怕是面对官方文档，也往往需要结合项目实践、踩过一些坑之后，才能真正理解每一个功能和参数的实际意义。因此，在本系列学习中，我不会采用简单罗列官方文档内容的方式来介绍 Jenkins，而是更注重用中学。我们将从配置一个简单的项目开始，先动手，再理解。在这个过程中，遇到哪些概念或语法，就再深入讲解对应的知识点，做到学以致用。

日常工作中，最基础的一类持续集成场景，往往出现在前端项目中：只需将开发完成的代码同步到远程主机上的指定目录即可。这种场景不涉及复杂的构建、测试或打包，属于 CI/CD 中的入门级任务。因此，我们将以此为例，通过创建一个简单的 Jenkinsfile 文件来模拟这类发布流程，暂不考虑构建或编译等细节，重点放在理解流水线语法结构和基本用法，为后续深入学习打下良好基础。

安装pipeline插件

在创建pipeline类型作业的时候，需要提前安装好pipeline插件，否则可能会出现找不到pipeline类型的作业。进入插件管理，搜索pipeline然后安装，我这里已经安装好了

插件安装好后，我们就可以创建一个方法一：直接在Jenkins内置的流水线编辑器 pipeline code 的文本框进行编写

方法二：将jenkinsfile存放到代码仓库，使用代码仓库中的jenkinsfile

通知

在 Jenkins 里，我们经常希望把任务的执行结果及时告诉相关人员，比如构建成功了，失败了，或者哪里出了问题。这就涉及到了 Jenkins 的通知功能。

Jenkins 通常会在流水线的构建后处理阶段，也就是 pipeline 中的 post 块去发送这些通知。最常见的通知方式就是 Email，Jenkins 自带了邮件通知的功能，只要配置好邮箱服务器和收件人，就能发邮件提醒。如果你希望用一些更现代的工具，比如 Slack、钉钉、企业微信来推送构建信息，那也没问题，Jenkins 可以通过 WebHook 或者专门的插件来实现对接。想找这些插件的时候，可以在插件管理页面里搜索关键词 Build Notification，就能看到一堆和通知相关的插件。

邮件通知

安装支持邮件配置的Mailer插件和email插件，我这里已经安装好了

依次点击 系统管理 → 系统配置，Jenkins管理员的邮箱地址在 Jenkins Location 系统配置段中的定义，该邮箱地址将为作为发给项目owner的通知邮件的发件人地址(From)

配置 SMTP 时的用户名要和你在系统管理员邮件地址里填写的一致，也就是说，两边填写的邮箱要相同。如果你用的是 QQ 邮箱，那用户名就是你的 QQ 邮箱地址，而密码这里不能填真正的邮箱密码，要填的是 QQ 邮箱给你生成的授权码，也叫认证码。这个授权码可以在 QQ 邮箱的设置里开启POP3/SMTP服务后生成，拿它来代替密码使用就行了。

测试邮件发送，如果能成功收到邮件，说明咱们的配置是正确的哟！

下面我们来测试 Email 通知功能，在freestyle流水线配置中，在构建后操作里选择E-mail Notification即可在流水线上启用Email通知功能

每次不稳定的构建都发送邮件通知表示只有构建失败才会发送通知单独发送邮件给对构建造成不良影响的责任人表示用于将邮件单独发送给提交代码而导致构建失败的责任人

为了有意进行失败的构建从而触发通知以便进行测试，这里在shell脚本中使用了exit命令

执行构建，发现构建失败

此时邮箱也收到了构建失败的邮件通知，通过链接可跳转至Job的构建状态页面，分隔线下面的内容是附加的构建日志

在 Jenkins 的 Pipeline Job 中，如果你想在流水线运行结束后发送邮件通知，可以在声明式 Pipeline 的 post {} 块中使用 mail 这个步骤（step）来实现。示例如下，当构建成功或失败时，都会发送对应的邮件通知。下面是具体的模板信息，这里我只设置了成功、失败两种情况，当然还有其他情况，大家根据实际情况配置即可。

执行构建，此时邮箱也收到了构建成功的通知

DingTalk通知

在接收构建通知的钉钉群上，创建机器人，配置钉钉群机器人的方法：群设置 → 智能群助手 → 添加机器人 → 自定义

使用钉钉机器人发送构建通知，在Jenkins上部署DingTalk插件，我已经安装了DingTalk插件

在Jenkins上的系统管理中配置钉钉，点击钉钉就可以进入到钉钉的配置页面

配置通知时机

新增机器人，填写钉钉的webhook及关键字信息，配置完成后点击Submit提交任务

如下图所示，钉钉测试邮箱成功了

配置 freestyle 作业使用钉钉机器人通知

构建job，并发送钉钉信息推送

在 Jenkins 的 Pipeline Job 中，如果你想在流水线运行结束后发送钉钉通知，可以在声明式 Pipeline 的 post {} 块中使用 dingtalk 这个步骤（step）来实现。示例如下，当构建成功或失败时，都会发送对应的邮件通知。下面是具体的模板信息，这里我只设置了成功、失败两种情况，当然还有其他情况，大家根据实际情况配置即可。

进行构建操作，不管成功或失败，都会接收到告警信息

WeChat通知

在 Jenkins 流水线中，我们可以通过企业微信机器人，把构建成功或失败的消息第一时间推送到群聊里。在 Jenkins 上安装插件，打开 Jenkins → 系统管理 → 插件管理，搜索插件 Qy Wechat Notification，安装插件并重启 Jenkins

在企业微信群里创建机器人，打开你想接收通知的微信群聊，点击右上角群设置→群机器人。拿到Webhook地址，这就是接下来我们要在 Jenkins 中用到的

配置 freestyle 作业使用企业微信群机器人通知，打开你要配置通知的 Job（构建任务）→ 配置。在构建后操作中，点击添加构建后操作步骤。选择企业微信通知。企业微信群机器人的Webhook端点地址。设置发送条件，比如我们这里设置的是仅在构建失败时发送