我做了这么多年持续集成和交付见过太多团队在 Jenkins 上栽跟头。有的卡在安装环境有的被插件依赖搞到崩溃还有的明明配置好了却总是构建失败最后干脆回到手工打包上传的老路。说实话Jenkins 本身并不难难的是你被一堆碎片化教程牵着走今天装个插件、明天配个权限始终没能形成一条完整的自动化流水线。这篇教程我打算换个思路直接带你走一遍从零到一的完整闭环装好 Jenkins、配好国内镜像加速、连上 GitLab、自动化构建 Java Web 应用、构建结果推送到钉钉、最后把部署包自动发到服务器并执行发布脚本。这一套流程跑通之后你就知道 Jenkins 到底是什么了。它不是某个孤立工具而是整个 DevOps 流程的发动机负责把代码变成线上服务的每个环节都自动化。我不会端着讲一堆抽象概念全程都是实际可执行的命令和配置。适合刚接触持续集成的开发、测试、运维同学也适合那些已经装了 Jenkins 但一直只用来手动点“构建”按钮的团队。按照这篇教程走一天时间完全够用剩下的就是你在真实项目里把细节慢慢填进去。1. 安装部署先把 Jenkins 跑起来1.1 环境准备JDK 版本别选错很多人第一步就卡在 JDK 版本上。Jenkins 新版对 Java 版本有硬性要求不同版本对应的 JDK 不一样装错了轻则警告重则直接起不来。当前主流 Jenkins 版本2.3xx 系列要求 JDK 11 或 JDK 17老一点的 2.2xx 系列有的还支持 JDK 8。我个人的建议是能上 JDK 17 就上 17因为新版本 Jenkins 官方已经逐渐把运行时基线往 17 上迁移了你用一个长期支持的版本后面升级插件、升级 Jenkins 本身都会顺畅很多。注意这里说的 JDK 是 Jenkins 自己运行需要的 Java 环境和你项目构建用的 JDK 是两回事。项目用 JDK 8 编译、Jenkins 用 JDK 17 跑完全没问题。后面配置全局工具的时候可以单独指定别混在一起。安装 JDK 在 Linux 上有两种常见方式。如果是 CentOS/RHEL 系用 yum 装# 先看看默认源里有没有 yum list java-17-openjdk* # 安装 yum install -y java-17-openjdk java-17-openjdk-develUbuntu/Debian 系则是apt update apt install -y openjdk-17-jdk装完以后验证一下版本输出类似openjdk version 17.0.x就说明没问题。这个环节别跳过我见过有人装了半天的 Jenkins 起不来最后发现是 JAVA_HOME 压根没设置系统默认还是老版本的 Java。1.2 Linux 安装 Jenkins官方源与手动部署两种方式Linux 安装 Jenkins 最省心的做法是用官方仓库。CentOS 系执行# 添加 Jenkins 仓库 sudo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io-2023.key # 安装 yum install -y jenkinsUbuntu/Debian 系curl -fsSL https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key | sudo tee /usr/share/keyrings/jenkins-keyring.asc /dev/null echo deb [signed-by/usr/share/keyrings/jenkins-keyring.asc] https://pkg.jenkins.io/debian-stable binary/ | sudo tee /etc/apt/sources.list.d/jenkins.list /dev/null apt update apt install -y jenkins装好以后启动systemctl start jenkins systemctl enable jenkins但这里我要多说一句如果你所在的网络环境访问 Jenkins 官方源和官方更新中心速度很慢那在线安装方式会非常折磨人。我遇到过下载一个 war 包要一小时、装插件装到一半超时的情况。所以更推荐第二种方式直接下载 jenkins.war 包用java -jar跑。这种方法没有平台绑定不管 Linux 还是 Windows 行为完全一致而且后续想去哪台机器部署拷过去就能用。# 创建专用目录 mkdir -p /opt/jenkins cd /opt/jenkins # 下载 war 包建议下载稳定版 wget https://get.jenkins.io/war-stable/latest/jenkins.war # 启动 java -jar jenkins.war --httpPort8080想后台运行就配合 nohupnohup java -jar jenkins.war --httpPort8080 /var/log/jenkins.log 21 这种方式的好处是你可以完全掌控 Jenkins 的启动参数和运行环境。比如指定 JVM 内存、指定 Jenkins 工作目录nohup java -Xms512m -Xmx2048m -DJENKINS_HOME/data/jenkins_home -jar jenkins.war --httpPort8080 /var/log/jenkins.log 21 JENKINS_HOME 这个变量非常关键所有 Jenkins 的配置、插件、构建记录都存这里面。建议从一开始就规划好这个目录放到一个大分区里别默认放在根目录构建记录多起来以后磁盘很容易被打满。1.3 Windows 安装一路下一步就行Windows 上安装 Jenkins 就没什么技术含量了。去官网下载 Windows 安装包.zip 或 .msi 都行解压或者安装之后直接访问http://localhost:8080就可以。不过 Windows 环境有两个容易踩的坑提前帮你排掉第一个是 JDK 路径问题。Windows 下如果通过 msi 安装Jenkins 服务默认用系统 PATH 里的 Java如果你系统里装了好几个 Java 版本可能 Jenkins 起来的时候加载了错误的版本。解决方法是到C:\Program Files\Jenkins\jenkins.xml里手动指定 java 路径executableC:\Program Files\Java\jdk-17\bin\java.exe/executable第二个是权限问题。Windows 服务模式下 Jenkins 默认以 LocalSystem 运行访问网络共享目录、映射驱动器这类操作经常失败。建议给 Jenkins 服务单独指定一个有权限的账号运行或者直接改用java -jar jenkins.war的命令行方式有人值守调试阶段用这种方式最省心。1.4 离线安装没外网的场景也能搞定离线安装这个场景我必须单独开一截说因为很多公司服务器是不连外网的而 Jenkins 对网络的依赖恰恰又很强。网上很多教程直接来一句“连不上网就装不了”这完全错误。实际上Jenkins 的离线安装方案非常成熟就三个核心问题war 包、插件包、依赖源。war 包的离线解决最简单在一台能上网的机器上提前下载好jenkins.war拷贝到目标服务器直接java -jar跑就行这一步不依赖网络。插件的离线就要多花点心思。Jenkins 的插件都是 .hpi 或 .jpi 格式你可以在能上网的机器上从 Jenkins 插件仓库把需要的插件下载下来然后拷贝到离线服务器的JENKINS_HOME/plugins目录重启 Jenkins 即可识别。但这里有个坑插件之间是有依赖关系的你下载 A 插件它可能依赖 B 插件和 C 插件B 和 C 又依赖 D。手动一个个下载很容易漏装完插件发现缺少依赖界面直接报错。我推荐的做法是先在线环境下装好 Jenkins把需要的插件全都装好然后把JENKINS_HOME/plugins整个目录打包拷到离线服务器上覆盖过去。这样依赖关系是完整的不会缺东少西。之后再根据实际需求增量补充插件。经验之谈公司做离线部署的话维护一套内部的插件仓库很重要。Jenkins 的插件配置支持自定义 Update Site 地址只需要改成内网地址即使在离线环境也能通过界面搜索和安装插件前提是你把需要的插件文件都放到内网这个地址上。这个思路跟前面提到的国内镜像源加速是同一个原理后面详细说。2. 基础配置把加速和凭据一次搞定2.1 插件源换成国内镜像解决安装慢与失败问题Jenkins 启动后第一步一定是安装插件这也是新手最痛的地方默认插件源在国外访问速度极慢经常安装到一半就失败。解决办法很直接把 Update Site 换成国内镜像地址。进入Manage Jenkins→Plugins→Advanced settings把Update Site里的 URL 替换成国内镜像https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json改完以后点击Check now重新拉取插件列表。这一步做完插件安装速度会有质的提升。但要注意一个问题Jenkins 的插件下载实际是从updates.jenkins.io下载具体文件的仅仅替换 Update Site URL可能只改了元数据部分插件文件还是要访问国外地址。所以你需要同时修改一个位于JENKINS_HOME/hudson.model.UpdateCenter.xml的文件改完 Update Site URL 后找到JENKINS_HOME/updates/default.json执行替换命令sed -i s/https:\/\/updates.jenkins.io\/download/https:\/\/mirrors.tuna.tsinghua.edu.cn\/jenkins/g /var/lib/jenkins/updates/default.json sed -i s/https:\/\/www.google.com/https:\/\/www.baidu.com/g /var/lib/jenkins/updates/default.json第二个替换是处理插件安装时 Google 统计接口超时的问题。改完以后重启 Jenkins再去装插件速度完全是两个世界。2.2 全局工具配置JDK、Maven、Git 一个都不能少插件装好以后就该配置构建环境了。进入Manage Jenkins→Tools这里配置 JDK、Maven、Git 等全局工具。配置完了以后流水线里就能直接用名字引用这些工具不用再写死本机路径。JDK 配置建议勾选Install automatically然后选择一个版本让 Jenkins 自己下载。但如果你处于内网环境或者不想让 Jenkins 下 JDK就取消自动安装手动填本机 JDK 的JAVA_HOME路径Name: JDK17 JAVA_HOME: /usr/local/jdk-17Maven 也推荐用自动安装选择版本即可。但如果你的项目依赖的是公司私服那 Maven 的配置文件settings.xml必须提前准备好然后在全局配置里指定Name: Maven3 MAVEN_HOME: /opt/maven/apache-maven-3.9.xMaven 还有一个关键配置项是Settings file in filesystem在这里直接指定你公司的 settings.xml 路径这样所有任务的 Maven 命令都会自动使用私有仓库地址省得每个任务都要配置一遍。Git 的配置相对简单只要 Jenkins 所在机器装了 Git填好Path to Git executable即可。如果是默认路径/usr/bin/gitJenkins 会自动检测到。2.3 凭据管理连接 GitLab 的三种方式从 GitLab 拉代码必须要有凭据Credentials。很多新手在这里搞不明白我详细说一下。Jenkins 的凭据系统是用来存储敏感信息的可以存 GitLab 密码、SSH 私钥、Token 等。在Manage Jenkins→Credentials里统一管理。连接 GitLab 通常有三种方式第一种是用户名密码方式。在凭据里添加Username with password填上你的 GitLab 用户名和密码。这种方式简单但在开启了 2FA 的 GitLab 上会失败因为账号密码不能用于 API 验证。第二种是 SSH 密钥方式。在 Jenkins 所在服务器上生成一对 SSH 密钥ssh-keygen -t rsa -b 4096 -C jenkinsyourcompany.com然后把公钥id_rsa.pub配置到 GitLab 账号的 SSH Keys 里私钥在 Jenkins 凭据里以SSH Username with private key形式保存。Git 拉取地址选择 SSH 格式gitgitlab.xxx.com:group/project.git。第三种是访问令牌Personal Access Token方式。在 GitLab 的用户设置里生成一个 Token勾选read_repository、write_repository、api等权限然后在 Jenkins 里用Username with password保存用户名填 GitLab 用户名密码填 Token。我个人的建议是无脑用 SSH 方式。为什么因为 SSH 密钥不像密码有有效期问题也不受 2FA 影响只要公钥不删除密钥一直有效。而且 SSH 通过 Git 协议传输数据效率更高。验证凭据是否配置正确的技巧在 Jenkins 里新建一个自由风格任务源码管理选择 Git仓库地址填 GitLab 的 SSH 地址如果 Select 凭据下拉框旁边不再提示红色报错就说明凭据验证通过了。这是最直观的测试方法。2.4 环境变量搞清楚 Jenkins 内置的常用变量Jenkins 内置了一批环境变量配置流水线时经常用到。很多人不熟悉这些变量总喜欢在脚本里写死路径结果迁移环境就炸了。我列几个最常用的变量说明示例值JENKINS_HOMEJenkins 工作目录/var/lib/jenkinsJOB_NAME任务名称my-web-appBUILD_NUMBER构建编号45BUILD_URL构建页面地址http://jenkins:8080/job/my-web-app/45/WORKSPACE项目工作目录/var/lib/jenkins/workspace/my-web-appGIT_COMMIT本次构建的 Git 提交 IDa1b2c3d4...GIT_BRANCH本次构建的分支origin/master这些变量在 Pipeline 脚本里可以直接用env.XXX引用比如env.BUILD_URL。在 Shell 构建步骤里则用$WORKSPACE、$BUILD_URL这种方式。我记得有次排查问题一个同事的脚本里硬编码了/home/user/workspace换了一台构建机器后全部构建失败。后面我一查发现他就是没理解WORKSPACE这个变量才是当前项目的实际工作目录。搞懂这些内置变量你的流水线脚本才具备可迁移性。3. 自动化部署实战从代码到上线全流程3.1 整体流程设计先想清楚再动手配置 Jenkins 自动化之前先把流程在脑子里过一遍。我的设计思路是这样的开发推代码到 GitLab 的 master 分支 → GitLab 通过 Webhook 通知 Jenkins → Jenkins 从 GitLab 拉取最新代码 → Maven 执行编译打包 → 将产物jar/war上传到目标服务器 → 在目标服务器执行部署脚本停旧服务、替换包、启动新服务→ 构建结果推送到钉钉群。每一步都可以单独调试不要一次性全配完再试不然报错都找不到是在哪一环出的问题。我习惯先跑通“拉代码 编译打包”这一段确认没问题后再加部署和通知环节。3.2 创建 Pipeline 任务脚本化的优点我强烈建议直接使用 Pipeline 类型的任务而不是自由风格任务。为什么因为 Pipeline 把整个构建过程写成了代码可以保存在 Git 仓库里后续维护、评审、回滚都有迹可循。自由风格任务虽然配置快但关键信息散落在 Web 界面里换一台 Jenkins 机器就得全部手工重配。新建任务类型选Pipeline然后在 Pipeline 脚本区域输入 Jenkinsfile 内容。下面是一个针对 Java Web 应用的完整示例pipeline { agent any tools { jdk JDK17 maven Maven3 } environment { // 引入 GitLab 凭据设为环境变量 GIT_CREDENTIALS credentials(gitlab-ssh-key) } stages { stage(Checkout) { steps { checkout([ $class: GitSCM, branches: [[name: */master]], userRemoteConfigs: [[ url: gitgitlab.xxx.com:your-group/my-web-app.git, credentialsId: gitlab-ssh-key ]] ]) } } stage(Maven Build) { steps { sh mvn clean package -DskipTests -q } } stage(Deploy) { steps { sh # 将构建产物上传到目标服务器 scp target/my-web-app.war deployer192.168.1.100:/opt/deploy/ # 远程执行部署脚本 ssh deployer192.168.1.100 bash /opt/deploy/deploy.sh my-web-app.war } } } post { success { // 构建成功通知 dingtalk( robot: my-robot, msgtype: text, text: 构建成功: ${env.JOB_NAME} #${env.BUILD_NUMBER} ) } failure { dingtalk( robot: my-robot, msgtype: text, text: 构建失败: ${env.JOB_NAME} #${env.BUILD_NUMBER} ) } } }3.3 Maven 构建 Java Web 应用参数选择与踩坑Maven 构建阶段看似简单实际上有很多细节决定成败。命令mvn clean package人人会写但里面的参数值得说一说。-DskipTests表示跳过单元测试执行但依然编译测试代码。如果想让测试代码都不编译用-Dmaven.test.skiptrue。这两个参数的区别很多老手都会混淆。CI 环境里我通常用-DskipTests这样既能保留测试代码编译的校验又不会因为某个测试失败卡住整个流水线。如果项目对代码质量要求高、测试必须全绿才允许构建那就不加这个参数让 Maven 跑完整测试。-q参数是安静模式只输出错误信息不会把一堆[INFO]日志刷满整个控制台。构建日志太长反而影响问题定位。还有一个容易忽略的是 Maven 仓库的本地缓存路径。Jenkins 默认的 Maven 本地仓库在~/.m2/repository下每个执行 agent 的~指向谁决定了缓存是否共享。如果你有多套 Jenkins 任务构建同一个项目建议在 Maven 配置里显式设置 Local Repository 路径settings localRepository/data/maven-repo/localRepository /settings共享本地仓库能节省大量重复下载依赖的时间。我见过一个项目第一次构建要下载几百 MB 依赖配置共享缓存之后后续构建只需要 10 秒以内。3.4 自动上传部署包并远程执行脚本构建产物出来以后接下来就是部署环节。这里的实现方式五花八门有人用 Publish Over SSH 插件有人用 Ansible有人直接 scp。我的建议是如果目标服务器不多几台以内纯 SSH Shell 脚本最直接也最容易排查问题如果目标服务器有成百上千台那我推荐用 Ansible 这类批量运维工具。用 Publish Over SSH 插件的话需要先在Manage Jenkins→System里配置远程服务器信息指定 SSH 私钥和远程目录然后在 Pipeline 里用sshPublisher步骤。这种方式把服务器列表和文件传输都可视化展示了对团队协作更友好。但我个人更喜欢直接写脚本来做。因为 SSH SCP 的方式可以在一个阶段里同时完成文件传输和远程命令执行流程完全透明。而且一旦服务器密钥变更直接在脚本里调整即可不需要动 Jenkins 配置。一个经验是部署脚本的编写有讲究好的部署脚本必须包含三个要素备份旧版本、容错处理、日志记录。下面是一个参考脚本#!/bin/bash # deploy.sh - 通用 Java Web 应用部署脚本 APP_NAME$1 DEPLOY_DIR/opt/app/my-web-app BACKUP_DIR/opt/backups # 1. 备份当前运行的版本 if [ -f $DEPLOY_DIR/$APP_NAME ]; then TIMESTAMP$(date %Y%m%d%H%M%S) cp $DEPLOY_DIR/$APP_NAME $BACKUP_DIR/${APP_NAME}.${TIMESTAMP} echo [INFO] Backed up to $BACKUP_DIR/${APP_NAME}.${TIMESTAMP} fi # 2. 停止旧服务这里以 Spring Boot 的 jar 包为例 PID$(pgrep -f my-web-app.jar) if [ -n $PID ]; then kill -15 $PID sleep 10 # 等待进程完全退出必要时强杀 if kill -0 $PID 2/dev/null; then kill -9 $PID fi fi # 3. 替换部署包 cp /opt/deploy/$APP_NAME $DEPLOY_DIR/my-web-app.jar chmod x $DEPLOY_DIR/my-web-app.jar # 4. 启动服务 cd $DEPLOY_DIR nohup java -jar my-web-app.jar --spring.profiles.activeprod app.log 21 # 5. 等待服务启动成功 for i in {1..30}; do if curl -s http://localhost:8080/actuator/health | grep -q UP; then echo [INFO] Application started successfully exit 0 fi sleep 2 done echo [ERROR] Application failed to start exit 1看到没有脚本里每一步都有明确的日志输出。这样 Jenkins 构建日志里每一步都是可见的出了问题能直接定位。3.5 配置 GitLab Webhook实现推送即构建代码推送到 GitLab 后怎么触发 Jenkins 构建两种方式轮询和 Webhook。轮询是 Jenkins 每隔一段时间去 GitLab 看代码有没有变化效率低而且有延迟。Webhook 是 GitLab 主动通知 Jenkins毫秒级响应。配置 Webhook 的流程在 Jenkins 的 Pipeline 任务里打开Build Triggers勾选Build when a change is pushed to GitLab复制生成的 GitLab webhook URL。打开 GitLab 项目的Settings→Webhooks粘贴这个 URL选择触发条件Push events 即可。生成一个 Secret Token 填在 GitLab 的 Webhook 设置里同时把这个 Token 配到 Jenkins 任务的触发高级设置中。这一步是安全校验防止别人随意触发你的构建。配置完成后本地改完代码 push 到 GitLab几秒内 Jenkins 就会收到通知并开始构建。构建状态会直接显示在 GitLab 的提交记录里。3.6 钉钉通知用自定义消息让构建状态一目了然构建结果通知看着简单实际做起来对体验的影响非常大。大家在钉钉群里看到构建成功或者构建失败的消息谁干的哪个分支构建了多久产物下载地址在哪这些信息都应该在消息里体现出来。Jenkins 有官方的钉钉插件用起来还算方便。安装插件后在系统配置里添加机器人Robot 名称自定义Webhook 地址填钉钉自定义机器人的 Webhook然后在 Pipeline 里就能用dingtalk步骤了。但如果你想更灵活地控制消息内容可以直接用 HTTP Request 插件调用钉钉机器人 Webhook。钉钉机器人的消息格式就是个 JSON POST 请求stage(Notify) { steps { sh curl -X POST https://oapi.dingtalk.com/robot/send?access_tokenYOUR_TOKEN \ -H Content-Type: application/json \ -d { msgtype: text, text: { content: 构建完成: ${env.JOB_NAME} #${env.BUILD_NUMBER}\\n分支: ${env.GIT_BRANCH}\\n地址: ${env.BUILD_URL} } } } }钉钉自定义机器人的配置要注意最后一定要加上加签密钥否则外部的人一旦拿到 Webhook 地址就能往你群里发垃圾消息。在钉钉机器人安全设置里选择“加签”把密钥拼接到 POST 请求的签名上。4. 常见问题与排查技巧实录4.1 构建报错 Docker daemon 连接失败热词里有一条很典型的报错docker: error response from daemon: get https://registry-1.docker.io/v2/。这种问题的根源是 Jenkins 构建过程中调用了 Docker 命令但 Docker daemon 没有正常运行或者当前用户没有访问 Docker socket 的权限。排查分三步走先看 Docker 服务是否在跑systemctl status docker如果没跑启动它systemctl start docker systemctl enable docker再看 Jenkins 用户有没有 docker 组权限usermod -aG docker jenkins # 修改后必须重启 Jenkins 才能生效 systemctl restart jenkins最后看构建机器网络能不能访问 Docker Hub。如果不能就需要给 Docker 配置国内镜像加速或者换用内网镜像仓库地址。这部分每个公司的方案不一样但思路就是让docker pull找到一个可达且稳定的镜像源。注意修改用户组权限后必须重启 Jenkins否则新权限不会加载到 Jenkins 进程里。这是最容易被忽略的一步。4.2 插件安装失败镜像源没配对插件安装失败 99% 是镜像源没配置好。按照前面 2.1 节的方式配置好国内镜像源并且把default.json里的下载地址也替换掉插件安装就会顺利很多。但还有一种情况某个插件在镜像源上同步不及时安装时提示 404。这时候的应急方案是去 Jenkins 插件官网搜索这个插件的 .hpi 文件手动下载后上传到Manage Jenkins→Plugins→Advanced settings→Deploy Plugin页面进行离线安装。这个机制同样适用于内网环境。公司内部维护一个插件镜像把常用插件都同步好开发环境用内网地址直接装。4.3 首次启动显示“Jenkins 实例似乎已离线”热词里也提到了这个问题“离线 该jenkins实例似乎已离线”。这其实是 Jenkins 的一个常见误报原因通常是 Jenkins 无法访问其默认的更新中心。解决方案有两类如果环境允许联网直接把更新中心地址换成国内镜像如果环境不允许联网那就配置离线模式在Manage Jenkins→Manage Plugins→Advanced settings里把 Update Site 留空然后勾选Enable offline mode之类的选项新版 Jenkins 可能叫不同名字这样 Jenkins 就不会反复尝试连接网络了。这类问题的核心思想是Jenkins 检测不到更新中心不代表本身功能有问题只是无法从网络获取插件信息而已。明白这一点你就能正确地区分“真离线”和“假离线”。4.4 凭据验证失败排查 GitLab 连接问题的顺序配好 GitLab 后拉代码时凭据一直报错这类问题按照下面的顺序排查基本十分钟内能定位第一确认仓库地址格式。SSH 方式一定要用gitgitlab.xxx.com:group/project.git格式用成 HTTPS 格式但选了 SSH 凭据必然失败。第二确认 Jenkins 服务器能访问 GitLab 服务器。在该服务器上手动执行ssh -T gitgitlab.xxx.com看是否返回欢迎信息。第三确认私钥权限。SSH 对密钥文件权限很敏感私钥必须是 600 权限否则会被拒绝chmod 600 ~/.ssh/id_rsa第四确认公钥确实配置到了正确的 GitLab 账号上。如果你在 GitLab 里用的是项目部署账号就要把公钥配到那个账号下而不是你自己个人的账号下。这个低级错误导致排查了一晚上的案例我见得太多了。4.5 Jenkins 面试题理解原理比背答案重要写 Jenkins 教程面试场景也值得提一嘴。现在很多公司招 DevOps 或者后端开发都会问到 Jenkins 相关问题。高频问题有这些Jenkins 和 GitLab CI/CD 有什么区别本质都是 CI/CD 工具区别在于 Jenkins 独立部署、插件生态丰富、支持各种语言和平台GitLab CI 集成在 GitLab 里使用简单但灵活性不如 Jenkins什么是 Pipeline为什么用 PipelinePipeline 把构建、测试、部署流程写成代码方便版本控制、复用和评审如何保证构建环境一致性使用固定版本的 JDK、Maven、Node通过工具链配置或者 Docker Agent 隔离环境构建产物怎么管理一键回滚需要保留多个历史版本删除策略要结合磁盘空间规划Jenkins 高可用怎么实现多节点 Master/Agent 架构调度器分发任务到不同 Agent这些问题光背答案不够我建议你亲手把教程里的流程完整走一遍理解每一步的意义。面试官追问细节的时候你才能说出自己的理解。比如问到 Pipeline 和自由风格任务的区别你可以说“自由风格任务适合简单的构建场景配置都在界面上完成但不好版本化Pipeline 把构建逻辑写成 Groovy 脚本我看一眼就能知道整个构建流程的每一步。我们都把它存到 Git 仓库里哪次构建出问题看历史记录就能对比差异。” 这种回答比背概念加分得多。4.6 环境变量和凭据在脚本中的使用最后把环境变量和凭据的使用再串一遍。在 Jenkins Pipeline 中声明环境变量有两种方式全局environment块和withEnv临时环境变量。全局方式environment { APP_ENV prod MAVEN_OPTS -Xmx1024m }临时方式steps { withEnv([APP_ENVdev]) { sh echo $APP_ENV } }凭据类变量用credentials()方法引用environment { DEPLOY_PASS credentials(deploy-pass) }如果凭据类型是 Secret textcredentials()返回的就是纯文本值如果是 Username with password返回的是username:password格式的字符串。这个区别要记清楚否则拼接命令的时候会出现语法错误。写在最后一天时间怎么分配我见过太多人学 Jenkins 半途而废根本原因是想一口吃成胖子。一会看插件列表一会看界面配置最后什么都没学会。所以特别建议你按照这篇教程的节奏来上午完成安装和基础配置下午完成一个 Java Web 应用的自动化部署全过程晚上再回来看常见问题对照自己的环境逐一排查。这样一天下来Jenkins 的完整使用链路你已经亲手走通了。项目上线之后我建议团队里每个人都掌握 Pipeline 的写法。因为往后的构建效率提升不会靠某个人的技巧而是靠团队把构建脚本当成真正的代码来维护。Jenkins 的价值就在这里它把重复的人工操作变成了标准化的自动化流程节省的是团队每个人每天的碎片时间积累起来非常可观。