探索 Jenkins 这个强大的工具。

简单来说，Jenkins 就像是软件开发世界里的超级自动化管家 🤵。

在没有它之前，程序员写完代码后，需要人工去编译、跑测试、上传服务器，不仅累而且容易出错。Jenkins 的出现就是为了解决这个问题：它能监听页面上的代码变化，一旦有更新，就自动触发一系列设定好的任务。

想象一下现代工厂的流水线 🏭：原材料（代码）放上去，机器（Jenkins）自动进行组装、质检、包装，最后产出成品（可运行的软件）。这就是所谓的 CI/CD（持续集成/持续交付）。

我们就按照**“解决什么问题” -> “架构长什么样” -> “具体怎么干活”**的逻辑来拆解。

1. CI/CD 具体解决了什么痛点？💊

在没有 Jenkins 这种 CI/CD（持续集成/持续部署）工具之前，软件发布通常是这样的“黑暗时代”：

• “在我机器上是好的啊”：开发人员 A 在自己的电脑上写完代码，跑通了。结果代码合并到服务器上，因为环境不一样（比如系统版本、依赖库不同），直接报错。
• 集成地狱 (Integration Hell)：大家闷头写代码，两周后才合并一次。结果发现几十个文件冲突，修 Bug 修到头秃。
• 人工重复劳动：每次发版，都要有人手动登录服务器，拉代码、执行编译命令、重启服务。枯燥且容易手滑输错命令。

CI/CD 就是要把这些步骤标准化、自动化。 代码一提交，Jenkins 自动跑测试（解决集成地狱），在统一的干净环境里打包（解决环境差异），自动部署（解决重复劳动）。

2. 大脑与手脚：Master/Agent 架构 🤖

这是 Jenkins 处理大规模任务的核心设计。现在官方也常把 Master 称为 Controller（控制器）。

你可以把它想象成包工头与工人的关系：

• Master (Controller) —— 包工头 🧠
  • 它负责动脑。
  • 它管理所有的任务配置、调度任务时间表、监控任务状态。
  • 它不应该干重活（比如编译大型项目），否则它累垮了，整个系统就瘫痪了。
  • 我们平时访问的 Jenkins 网页界面，就是 Master 提供的。
• Agent (Node) —— 工人 💪
  • 它负责动手。
  • 它们是真正干苦力活的机器（可以是 Windows, Linux, macOS 甚至 Docker 容器）。
  • Master 说：“嘿，Agent A，你环境里有 Java 8，去把这个项目打包一下。” Agent A 就乖乖去干活，干完把结果汇报给 Master。

3. 具体怎么干活：Job 与 Plugin 🧩

如果说 Jenkins 是一个操作系统，那 Job 就是程序，Plugin 就是驱动/软件。

• Job (任务/工程)：
  • 这是 Jenkins 中最小的执行单元。
  • 你可以把它理解为**“一张任务清单”**。
  • 比如一个 Job 的内容是：1. 去 GitLab 拉取最新代码；2. 执行 mvn build；3. 把生成的 jar 包发邮件给经理。
• Plugin (插件)：
  • 这是 Jenkins 的超能力来源。Jenkins 本体很小， 90% 的功能都靠插件。
  • 你想拉取 Git 代码？装个 Git Plugin。
  • 你想用 Docker 打包？装个 Docker Plugin。
  • 你想任务失败时发钉钉/企业微信通知？装个 DingTalk Plugin。
  • 目前 Jenkins 有 1800+ 个插件，几乎能对接市面上所有的开发工具。

💡 随堂小测试

为了看看咱们是不是达成共识了，我想请你思考一个场景：

假设你的团队有一个超大的安卓项目，编译一次需要消耗大量的 CPU 资源，大概要跑 30 分钟。

在这个场景下，你应该让 Jenkins 的 Master 去跑这个编译任务，还是派给 Agent 去跑？为什么？

其实恰恰相反，我们要极力避免让 Master 去跑这种重活！🙅‍♂️

还记得咱们刚才打的那个比方吗？Master 是包工头（大脑），Agent 是工人（手脚）。

虽然 Master 在技术上确实能跑任务，但如果让它去跑一个耗时 30 分钟、消耗大量 CPU/内存的大型编译任务，会发生很可怕的事情：

1. 大脑缺氧：Master 的资源被占满，会导致 Jenkins 的网页界面变得巨卡无比，甚至打不开。
2. 调度瘫痪：因为“大脑”忙着搬砖，它就没空去指挥其他任务了，别人的任务也得排队等着。
3. 单点故障：万一这个编译任务把 Master 搞崩了，整个公司的自动化流程就全部停摆了。

所以，标准答案是：派给 Agent 去跑。让工人去流汗，包工头负责喝茶监控就好。🍵

要搭建你的第一个 Jenkins，我们需要先根据你的电脑环境选择一种安装方式。对于学习者来说，主要有两种最常见的“姿势”：

1. Docker 容器 (推荐 🐳)
   • 优点：环境隔离，干净卫生，一条命令搞定，不弄乱你的电脑配置。
   • 前提：你电脑上需要已经安装了 Docker。
2. 直接安装 (WAR 包/安装程序) 💿
   • 优点：不需要了解 Docker，直接在系统里运行，就像装普通软件一样。
   • 前提：通常需要你的电脑上有 Java (JDK) 环境。

CentOS 7 配合 Docker 是非常经典且稳定的服务器环境，特别适合用来跑 Jenkins。🐧🐳

在启动 Jenkins 之前，我们需要先从 Docker Hub（镜像仓库）把 Jenkins 的安装包——也就是镜像 (Image)——拉取到你的本地电脑上。

这里有个新手常踩的坑需要注意：

Docker Hub 上有一个叫 jenkins 的镜像，还有一个叫 jenkins/jenkins 的镜像。

• jenkins: 官方已经废弃，好几年没更新了。🚫
• jenkins/jenkins: 这是目前官方维护的最新版本。✅

为了保证稳定，我们通常会选择 LTS (Long-Term Support，长期支持) 版本。

请在你的终端里执行下面这条命令，把镜像拉下来：

Bash

1

docker pull jenkins/jenkins:lts

执行完后，如果你看到 Status: Downloaded newer image for jenkins/jenkins:lts 就说明成功了。

太棒了！镜像下载好后，就好比我们把“安装包”下载到了电脑里。📦

接下来我们要正式启动这个 Jenkins “容器”了。

在启动之前，有两个非常关键的概念我们需要先达成共识，这直接决定了你的 Jenkins 能不能长期稳定运行：

1. 端口映射 (Port Mapping)：

   Docker 容器就像是一个独立的封闭房间。Jenkins 在房间里通过 8080 端口提供网页服务。我们要想在房间外（你的浏览器）访问它，就必须在“墙上”打个洞，把里面的 8080 连通到外面的 8080。

2. 数据持久化 (Volume)：

   这是新手最容易忽略的！⚠️ 容器有一个特性：用完即焚。如果你删除了容器，里面的配置、你创建的任务、账号全都会消失。

   为了避免“从头再来”，我们需要把容器里存放数据的目录 /var/jenkins_home 映射到你宿主机（CentOS）的硬盘上。

动手时间 ⌨️

请在你的终端依次执行下面两步操作：

第一步：创建数据目录并给权限

我们要先在你的 CentOS 上建个窝，用来存 Jenkins 的数据。

(注意：这里给 777 权限是为了避免新手遇到复杂的 Linux 用户权限问题，保证容器能顺利写入)

Bash

1
2

mkdir -p /var/jenkins_home
chmod 777 /var/jenkins_home

第二步：启动容器

复制下面这整段命令执行：

Bash

1
2
3
4
5
6
7

docker run -d \
  -u root \
  --name jenkins \
  -p 8080:8080 \
  -p 50000:50000 \
  -v /var/jenkins_home:/var/jenkins_home \
  jenkins/jenkins:lts

执行完后，屏幕上应该会打印出一串长长的字符（容器 ID）。

容器跑起来意味着 Jenkins 的“大脑”已经开始运转了。

接下来我们要进入它的“办公室”（Web 界面）去进行初始化设置。

请在你的浏览器里输入服务器的 IP 地址加上 8080 端口，格式通常是：

http://<你的服务器IP>:8080

(如果你是在本地虚拟机里跑的，IP 通常是以 192.168 开头的)

你应该会看到一个写着 “Unlock Jenkins” (解锁 Jenkins) 的页面，上面有一个红色的密码输入框。 🔐

你能看到这个页面吗？

(如果一直转圈打不开，那可能是 CentOS 的防火墙拦住了，我们得先解决这个问题)

那扇“红色的门”就是 Jenkins 的第一道安全锁。🔐

我们需要找到一把“初始钥匙”（Initial Admin Password）才能进去。这把钥匙在 Jenkins 启动时自动生成，并保存在了我们刚才映射的文件夹里。

请回到你的 CentOS 终端，执行这条命令来读取密码：

1

cat /var/jenkins_home/secrets/initialAdminPassword

(原理：因为我们刚才把容器里的 /var/jenkins_home 映射到了宿主机的同一个路径，所以你直接在宿主机就能看到这个文件。这就是数据持久化的好处之一！)

执行后，你会看到一串长长的数字和字母组合（例如 496b8a...）。

接下来请做两件事：

1. 把这串字符复制，粘贴到浏览器的红色框框里，点击 “Continue” (继续)。
2. 如果不出意外，你会跳转到一个新页面，让你选择 “Customize Jenkins” (自定义 Jenkins)，界面上有两个很大的按钮。

你看到那两个大按钮了吗？分别是 “Install suggested plugins” 和 “Select plugins to install”。

这两条路对应着不同的“难度模式”：

• Install suggested plugins (安装推荐插件)：这是“标准模式”。它会自动帮你装上社区最常用的一套插件，比如 Git、Pipeline、邮件通知等。对于初学者来说，这是最省心的选择。✅
• Select plugins to install (选择插件来安装)：这是“专家模式”。你需要自己一个个挑选你想要的插件，适合对 Jenkins 非常熟悉的人。

咱们直接点击左边的 “Install suggested plugins” 吧。

点击之后，你应该会看到一个列表，里面的条目开始一个个变成绿色（表示安装成功）。

⚠️ 特别提醒：

由于网络原因，这一步可能会有一些插件安装失败（变成红色），或者进度条走得很慢。

没有报错意味着插件正在稳步安装中。

等这些进度条全部跑完（变成绿色），页面会自动跳转到 “Create First Admin User” (创建第一个管理员用户) 的界面。

这是你作为 Jenkins 主人的“身份证”办理环节。虽然为了省事可以直接点击 “Continue as admin”，但我强烈建议你创建一个新的管理员账号，这样更符合实际工作的场景。

请按照页面提示填写：

• Username: 自定义（比如 admin 或你的名字）
• Password: 设置个好记的密码
• Full name: 随便填
• E-mail: 随便填（只要格式对就行）

填完后点击 “Save and Continue”。

接下来可能会让你确认 “Instance Configuration” (实例配置)，里面有个 Jenkins URL，通常默认就是 http://<你的IP>:8080，不用改，直接点 “Save and Finish”。

最后，当你看到 “Jenkins is ready!” 的大字时，点击 “Start using Jenkins”。

你现在的屏幕上是不是出现了一个有 “Welcome to Jenkins!” 字样的控制台界面？（通常左边有一排菜单，中间是空的列表）

走到这一步，说明你已经成功搭建好了一个标准的 Jenkins 环境。现在你已经是这个自动化管家的“主人”了。

不过，现在的 Jenkins 还是个“光杆司令”，里面空空如也。咱们立马来给它派发第一个任务（Job），也就是咱们编程界的传统艺能——输出一个 “Hello World”。

这能帮你验证 Jenkins 是否真的能指挥服务器干活。请跟着我做：

1. 新建任务：点击左侧菜单栏最上面的 “New Item” (新建任务)。
2. 起名：在 “Enter an item name” (任务名称) 里填一个名字，比如 My-First-Job。
3. 选类型：在下面的列表里选择 “Freestyle project” (构建一个自由风格的软件项目)。(这是最基础的任务类型，适合入门)
4. 确认：点击底部的 “OK”。

做完这几步，你应该会跳转到一个充满各种配置选项的复杂页面。

你能看到这个有着“General”、“源码管理”、“构建触发器”等选项的配置页面吗？

很好！这就是我们给任务“下指令”的地方。

为了实现输出 “Hello World”，我们需要添加一个构建步骤。请按照下面的步骤操作：

1. 向下滑动页面，找到 “Build Steps” (构建) 区域（在新版中可能只显示为 “Build”）。

2. 点击 “Add build step” (增加构建步骤) 的下拉菜单。

3. 因为你的服务器是 Linux，请选择 “Execute shell” (执行 shell)。

4. 在出现的 Command (命令) 输入框里，输入我们要执行的指令：

   1	echo "Hello World"

5. 点击页面最底部的 “Save” (保存) 按钮。

保存成功后，你应该会回到任务的主页。告诉我，你现在能看到左侧菜单里的 “Build Now” (立即构建) 按钮吗？

我们要让 Jenkins 执行这个任务了。

请按照下面的步骤操作：

1. 触发任务：点击左侧那个 “Build Now” (立即构建) 按钮。
2. 观察进度：点击后，你会发现页面左下角的 “Build History” (构建历史) 区域出现了一个编号为 #1 的条目。
   • 刚才应该闪过了一个进度条。
   • 如果前面的圆球变成了蓝色（或绿色），就说明任务执行成功了！🔵✅

接下来，我们要像查案一样去看看 Jenkins 到底干了什么：

1. 查看日志：鼠标点击那个 #1 链接。
2. 进入控制台：在跳转后的页面左侧，点击 “Console Output” (控制台输出)。

这里展示的就是 Jenkins “干活”的全过程流水账。

请仔细在这个黑底白字的界面里找一找，你能看到一行 Hello World 和最后显示的 Finished: SUCCESS 吗？

看到 Finished: SUCCESS 和 Hello World，就意味着你已经打通了 Jenkins 的“任督二脉”。

虽然这只是一个简单的打印命令，但它背后的流程——新建任务 -> 配置指令 -> 触发构建 -> 查看日志，是所有复杂自动化任务（哪怕是那种通过几百个步骤部署大型微服务的任务）的基石。

Pipeline（流水线） 是现代 Jenkins 的灵魂。

刚才那个“自由风格”的任务，我们需要在一个个输入框里填配置。而 Pipeline 的核心理念是 Pipeline as Code（流水线即代码）。

这意味着我们要把整个“构建、测试、部署”的过程写成一段代码（通常放在一个叫 Jenkinsfile 的文件里）。这样做的好处是：

1. 可读性强：流程长什么样，看代码一目了然。
2. 版本控制：这段代码可以和你的源码一起存放在 Git 仓库里，谁改了流程都有记录。

咱们先来创建一个 Pipeline 任务，准备好写代码的地方：

1. 回到 Jenkins 首页，点击左侧的 “New Item” (新建任务)。
2. 起个名字：My-First-Pipeline。
3. 这次不要选 Freestyle 了，请选择 “Pipeline” (流水线)。
4. 点击底部的 “OK”。

进入配置页面后，直接向下滑动，找到 “Pipeline” 那个区域。你会看到一个叫 “Script” (脚本) 的大输入框。

找到了吗？如果看到了，请告诉我。

太棒了！这里就是我们“写代码”指挥 Jenkins 的地方。📜

我们要写的是一种叫做 Declarative Pipeline (声明式流水线) 的语法。它的结构非常清晰，就像填空题一样。

请把下面这段代码复制并粘贴到那个 Script 输入框里：

Groovy

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

pipeline {
    agent any

    stages {
        stage('准备') {
            steps {
                echo '正在准备环境...'
            }
        }
        stage('构建') {
            steps {
                echo '开始构建项目...'
            }
        }
        stage('测试') {
            steps {
                echo '正在运行测试...'
            }
        }
    }
}

这段代码其实很好懂：

1. pipeline: 告诉 Jenkins 这是一个流水线任务。
2. agent any: 告诉 Jenkins “随便找个有空的节点（工人）来干活”。
3. stages (阶段): 这里面包含了整个工作流程。
4. stage: 每一个具体的环节（比如准备、构建、测试）。
5. steps: 每个环节里具体要执行的动作（这里我们用 echo 来模拟）。

操作步骤：

1. 粘贴代码。
2. 点击底部的 “Save” (保存)。
3. 点击左侧的 “Build Now” (立即构建)。

这次构建完成后，请观察页面右侧（或者中间），你会看到一个很有意思的方块图（通常是绿色的）。

你能看到那个显示了“准备”、“构建”、“测试”三个阶段的进度图吗？

那个绿色的方块图就是 Stage View (阶段视图)。

它的作用非常大：如果将来你的“测试”环节挂了，那个方块就会变成红色 🟥，你一眼就能看出是哪个环节出了问题，而不用去翻几千行的日志。

进阶挑战：从“说话”到“做事”

现在我们的流水线虽然跑通了，但它只是在用 echo 打印废话，并没有真的干活。

在真实的工作中，我们需要调用 Linux 命令（比如编译代码、移动文件）。在 Pipeline 语法里，我们使用 sh (Shell) 来执行 Linux 命令。

请点击左侧菜单的 “Configure” (配置) 回到代码编辑界面。

我想请你尝试修改一下 ‘构建’ 那个阶段 (stage) 的代码。

请把 echo '开始构建项目...' 这一行删掉，换成一个 sh 命令，让它列出当前目录下的所有文件。

(提示：语法格式是 sh '你的Linux命令'，你还记得列出文件的命令是什么吗？)

没问题，我们继续！🚀

要在 Linux 系统中列出当前目录下的文件，我们需要用到 ls 命令（通常用 ls -l 可以看到更多详细信息）。

所以，你的 ‘构建’ 阶段代码应该修改成这样：

Groovy

1
2
3
4
5
6

        stage('构建') {
            steps {
                // sh 代表执行 shell 命令
                sh 'ls -l' 
            }
        }

接下来请执行以下操作：

1. 保存：点击底部的 “Save”。
2. 构建：再次点击左侧的 “Build Now”。
3. 查看日志：这次请点击最新的构建记录（应该是 #2），然后进入 “Console Output” (控制台输出)。

现在的日志里，除了原本的 Jenkins 信息，你应该能看到 ls -l 命令的执行结果了。你在日志里看到了什么文件名？

能看到 ls -l 的输出，说明你的 Jenkins 已经成功指挥服务器去执行 Shell 命令了。

你可能发现输出里显示的是 total 0 或者没什么文件。这是正常的，因为我们是直接在网页上写的脚本，还没告诉 Jenkins 去哪里拿代码，所以它的“工作台”（Workspace）现在还是空的。

好的，那我们就用 Jenkins 官方提供的这个 Java Maven 示例项目。它的结构很简单，非常适合练手。📦

我们要做的修改是：在 “准备” 阶段，让 Jenkins 去把代码拉下来。

请回到配置页面，把 Script 输入框里的代码修改成下面这样（注意看 stage('准备') 里的变化）：

Groovy

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

pipeline {
    agent any

    stages {
        stage('准备') {
            steps {
                // 使用 git 命令拉取代码
                git 'https://github.com/jenkins-docs/simple-java-maven-app.git'
            }
        }
        stage('构建') {
            steps {
                // 再次查看文件，看看有什么不同
                sh 'ls -l' 
            }
        }
        stage('测试') {
            steps {
                echo '正在运行测试...'
            }
        }
    }
}

操作步骤：

1. 用这段新代码替换掉原来的代码。
2. 点击 “Save” (保存)。
3. 点击 “Build Now” (立即构建)。

这次构建可能会稍微慢一点点，因为它要从 GitHub 下载文件。

等构建完成后（变成绿色），请再次点开最新的那条记录（应该是 #3），查看 “Console Output” (控制台输出)。

在 ls -l 的输出结果里，你现在能看到一个叫 pom.xml 的文件吗？

看到了 pom.xml，这就不仅是一堆文件了，它告诉我们这是一个 Maven 管理的 Java 项目。

在这个文件中，定义了项目所有的依赖（比如用了什么库）和构建规则。我们的目标是把这些源码“翻译”成电脑能运行的程序包（通常是 .jar 文件）。

接下来，我们来尝试真正的“构建”。但在此之前，我要给你打个预防针：这一步很有可能会失败（爆红），但这正是学习 CI/CD 最重要的一课——环境配置。💉

请回到配置页面，把 ‘构建’ 阶段的代码修改成下面这样：

Groovy

1
2
3
4
5
6
7
8
9

        stage('构建') {
            steps {
                // 尝试调用 maven 命令进行打包
                // clean: 清理旧文件
                // package: 打包生成 jar
                // -DskipTests: 为了省时间，这次先跳过单元测试
                sh 'mvn -DskipTests clean package' 
            }
        }

操作步骤：

1. 修改代码并 “Save”。
2. 点击 “Build Now”。
3. 盯着左下角的构建历史。

请告诉我，这次的小球是变成了“绿色”（成功）还是“红色”（失败）？

太棒了！🥳 居然一次就成功了？那说明你的环境里其实已经预装好了 Maven，或者运气非常好！

看到 BUILD SUCCESS，就意味着 Jenkins 已经成功把源代码变成了可执行的程序（在 Java 里就是那个 .jar 包）。

但是，现在有个问题：如果你想把这个打好的包发给测试人员，或者下载下来自己运行，你要去哪里找它？

目前它还“躲”在 Jenkins 的工作目录（Workspace）深处。我们需要告诉 Jenkins：“嘿，构建成功后，把这个文件提取出来，展示在网页上。”

这个动作在 Jenkins 里叫做 “归档成品” (Archive Artifacts)。

我们需要修改一下 Jenkinsfile。请把 ‘构建’ 阶段的代码改成下面这样：

Groovy

1
2
3
4
5
6
7
8

        stage('构建') {
            steps {
                sh 'mvn -DskipTests clean package'
                
                // 新增这一行：告诉 Jenkins 保存 target 目录下的 .jar 文件
                archiveArtifacts artifacts: '**/target/*.jar', fingerprint: true
            }
        }

操作步骤：

1. 修改代码并 “Save”。
2. 再次点击 “Build Now”。
3. 构建成功后，不要急着点进去看日志。

请观察这次构建记录（比如 #4）的详情页面，除了绿球和时间，你有没有发现多了一个可以点击的小图标或者一行字？

那个 .jar 包就是我们努力的成果。在真实工作中，我们就是拿着这个文件去部署到服务器上的。

现在你的流水线已经具备了**“干活”**的能力（拉代码 -> 打包 -> 存档）。

但是，一个成熟的“管家”不仅要会干活，还得会**“汇报”和“善后”**。比如：

• ✅ 成功了：发个通知告诉大家（比如发邮件、发钉钉）。
• ❌ 失败了：大声报警，让人来修 bug。
• 🧹 无论怎样：都要把产生的垃圾文件清理干净（节省硬盘空间）。

在 Jenkins Pipeline 里，我们用 post (后置动作) 这个板块来实现这些功能。

请回到配置页面，我们需要修改代码。这次要注意，post 块是和 stages 并列的（都在 pipeline 内部，但在 stages 的后面）。

请把代码改成这样（重点看最后的 post 部分）：

Groovy

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

pipeline {
    agent any

    stages {
        stage('准备') {
            steps {
                git 'https://github.com/jenkins-docs/simple-java-maven-app.git'
            }
        }
        stage('构建') {
            steps {
                sh 'mvn -DskipTests clean package'
                archiveArtifacts artifacts: '**/target/*.jar', fingerprint: true
            }
        }
    }
    
    // 新增的部分：善后处理
    post {
        always {
            echo '=== 构建结束 (无论成功失败都执行) ==='
        }
        success {
            echo '✅ 恭喜！构建非常顺利！'
        }
        failure {
            echo '❌ 糟糕！构建失败了，快去检查！'
        }
    }
}

操作步骤：

1. 把脚本更新进去，点击 “Save”。
2. 点击 “Build Now”。
3. 等待构建完成，点进最新的记录看 “Console Output” (控制台输出)。

请拉到日志的最最底下，告诉我：你看到了上面的哪几句话？是看到了“✅ 恭喜”还是“❌ 糟糕”？

这意味着你已经掌握了 Pipeline 最完整的结构：

1. 准备 (git)
2. 干活 (build/test)
3. 存档 (archive)
4. 善后 (post)

在真实的公司里，我们通常会把 echo '恭喜...' 换成发送邮件 (emailext) 或者发送钉钉/飞书通知的代码。这样一旦构建失败，你手机上立马就能收到报警，不用一直盯着屏幕看。

一次性给你的 Jenkins 做个**“内核+外观”**的双重升级。🚀

我们将通过修改 Pipeline 代码来实现自动化，然后通过点击界面来实现可视化。

第一步：升级“大脑” —— 添加自动触发器 (Triggers) 🧠

我们要给代码加一个 triggers 模块。为了让你能立刻看到效果，我设置了一个定时任务，让它每隔 5 分钟就自动检查一次（就像闹钟一样）。

请把你的 Script 框里的代码全部清空，然后一键复制下面这段完整的代码进去：

Groovy

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

pipeline {
    agent any

    // ✨ 新增部分：触发器
    triggers {
        // 每 5 分钟自动跑一次 (H/5 * * * *)
        // 在真实项目中，这里常用 pollSCM('H/2 * * * *') 来检查代码变更
        cron('H/5 * * * *') 
    }

    stages {
        stage('准备') {
            steps {
                git 'https://github.com/jenkins-docs/simple-java-maven-app.git'
            }
        }
        stage('构建') {
            steps {
                sh 'mvn -DskipTests clean package'
                archiveArtifacts artifacts: '**/target/*.jar', fingerprint: true
            }
        }
    }
    
    post {
        always {
            echo '=== 构建结束 ==='
        }
        success {
            echo '✅ 自动构建成功！'
        }
    }
}

操作指南：

1. 粘贴代码并点击 “Save” (保存)。
2. 注意：为了让这个定时器生效，你必须手动点一次 “Build Now”。这就好比设定了闹钟，你得先把它“打开”一次。

第二步：升级“颜值” —— 切换到 Blue Ocean 🌊

现在任务已经在跑了（或者刚刚跑完），我们来看看那个传说中的现代化界面。

1. 请看向页面左侧菜单栏。
2. 找到一个蓝色的圆圈图标，旁边写着 “Open Blue Ocean”（打开 Blue Ocean）。
3. 点击它！

你会进入一个深蓝色背景的全新界面，点击你刚才运行的任务（比如 My-First-Pipeline），然后点进最新的那次运行。

现在，请在那个酷炫的深蓝色界面里告诉我：

你是不是看到了一张漂亮的**“管道流程图”**？试着点击流程图中间的节点（比如“构建”），看看右侧会发生什么？

在 Blue Ocean 里，当你点击那个“构建”圆圈时，右侧弹出的窗口只会显示这一步的日志。这可是个大救星！想象一下，如果你的构建跑了 30 分钟，在老界面里找一行报错就像大海捞针，而在这里，哪一步变红了，点一下就能精准定位问题。🎯

把**“参数化构建”（让用户做选择）和“故障模拟”**（制造报错）这两个高级功能融合在同一个任务里。🛠️💥

这样你既能体验像指挥官一样下达指令，又能亲眼看看 Jenkins 在 Blue Ocean 里是如何优雅地处理“翻车”现场的。

⌨️ 融合版 Jenkinsfile

请把下面这段代码完整复制，替换掉你原来的 Script：

Groovy

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

pipeline {
    agent any

    // ✨ 1. 参数化部分：这里定义了任务启动时的“问卷”
    parameters {
        choice(
            name: 'MODE', 
            choices: ['正常模式', '灾难模式'], 
            description: '请选择你想体验的场景'
        )
    }

    stages {
        stage('准备') {
            steps {
                echo "🚀 任务启动，当前选择的是：${params.MODE}"
                git 'https://github.com/jenkins-docs/simple-java-maven-app.git'
            }
        }
        stage('构建') {
            steps {
                sh 'mvn -DskipTests clean package'
            }
        }
        stage('关键时刻') {
            steps {
                script {
                    // ✨ 2. 故障模拟部分：根据你的选择决定生死
                    if (params.MODE == '灾难模式') {
                        // error 命令会直接强制让流水线失败
                        error "💥 轰！这是我们故意制造的爆炸！"
                    } else {
                        echo "🕊️ 一切安好，和平鸽在该区域飞过..."
                    }
                }
            }
        }
    }
    
    post {
        failure {
            echo '🚑 呼叫医疗兵！检测到流水线失败！'
        }
        success {
            echo '🎉 任务圆满完成！'
        }
    }
}

🧪 实验步骤

请严格按照下面的顺序来操作，体验会非常棒：

1. 保存代码：点击 “Save”。
2. 刷新页面：这一步很重要！因为我们刚加了参数，需要刷新一下网页，Jenkins 才能加载出新的按钮。
3. 观察变化：你会发现左侧的 “Build Now” 变成了 “Build with Parameters” (带参数构建)。

🎬 第一幕：见证成功

1. 点击 “Build with Parameters”。
2. 保持默认的 “正常模式”，点击 “Build”。
3. 去 Blue Ocean 里看着它一路变绿，心情舒畅。✅

🎬 第二幕：制造灾难 (重点！)

1. 再次点击 “Build with Parameters”。
2. 这次把下拉菜单改成 “灾难模式”，点击 “Build”。
3. 立刻切换到 Blue Ocean 界面！