简介这是一份面向DevOps工程师、研发及运维人员的Jenkins CI/CD实战指南源自Packt Publishing经典书目第三版内容包含从本地构建到生产部署的全流程实践。全书重点讲解如何搭建安全、弹性且成本可控的持续集成流水线并贯穿自动化测试、安全扫描与部署策略等关键环节。资源采用PDF格式共1个文件包体大小约20.13MB适合希望系统掌握Jenkins核心操作及DevOps最佳实践的读者阅读。目前已有47人浏览学习文件排版清晰、章节完整既可作为工具手册随时查阅也可作为团队内部培训的参考资料。通过阅读本书读者能够理解CI/CD体系中的角色分工学会利用Jenkins Pipeline实现代码提交后的自动构建、测试、制品管理与部署并结合实际案例排查流程中的常见问题同时将安全能力融入交付链路显著提升软件交付效率。建议配合本地搭建的Jenkins环境边读边练以更好吸收书中示例与排错思路。1. 先搞懂持续集成与部署解决什么问题再决定要不要上Jenkins周一早上十点开发群里的消息开始刷屏“这个包是不是没更新”“预发环境还是昨天的代码。”如果你在这样靠人肉打包传服务器的团队待过就会明白Jenkins持续集成与部署不是“多装一个工具”而是把“代码合并到主干之后自动完成构建、测试、归档、发布”这条链路变成一条可重复、可回溯、不依赖某个同事记忆的自动化产线。反直觉的结论是持续集成的成功标志不是流水线全绿而是发布当天团队不需要打开任何终端去敲打包命令。这篇文章写给两类人。一类是团队里刚被安排搭建集成环境的开发者想用最小成本把Jenkins跑起来另一类是已经用了一段时间、但每次发版还是战战兢兢的维护者想搞明白参数怎么调、故障怎么排查。我会按一条完整路径来讲先搭环境、再写Pipeline、然后解决部署和回滚、最后列高频踩坑记录。所有示例都以“能复现”为准不写那些只能在PPT里好看的演示。2. 环境搭建与全局配置从装好到能跑流水线要定的四件事Jenkins本身不复杂复杂的是它的运行环境。我第一次给内部项目配Jenkins时光是插件就装了十几个结果每次启动都要等很久构建队列还经常卡死。后来把所有插件清掉只留核心的几个整个世界安静了。这一章先解决“装好之后该干什么”再讲凭据和全局工具链这些决定你后面写流水线是顺风顺水还是一路踩坑。2.1 安装与初始化包管理器安装之后第一次登录先做这三件事常见做法是在一台Linux服务器上用包管理器安装。以Debian系发行版为例安装命令大致是sudo apt update sudo apt install openjdk-17-jre-headless jenkins sudo systemctl enable --now jenkins sudo cat /var/lib/jenkins/secrets/initialAdminPassword逻辑说明Jenkins是Java应用必须先装JRE。enable --now让服务开机自启并立即启动。初始管理员密码会写入/var/lib/jenkins/secrets/initialAdminPassword用cat读取后到Web界面粘贴。端口默认8080第一次访问会进入初始化向导。参数说明如果你的服务器内存只有2GB建议把JVM堆内存调小一点在/etc/default/jenkins里设置JAVA_ARGS-Xms256m -Xmx512m否则光Jenkins自己就把内存吃光了。插件安装那一步要果断选“跳过”后面只装需要的别贪多。初始化之后有三件事我建议立即做。第一在“系统管理→系统配置”里把Jenkins URL改成IP或域名很多webhook失败都是因为URL还留在localhost。第二创建管理员账号后把匿名用户的读权限关掉避免整个内网都能看构建日志。第三设置构建历史保留策略我一般保留最近30天或最近50次构建磁盘爆掉多半是没人管历史产物。2.2 凭据与权限把密码从构建脚本里赶出去很多团队的Jenkinsfile里还写着明文密码例如sshpass -p 123456。这种做法在内部网络可能一时没事但一旦代码仓库权限没控好就等于把生产服务器的钥匙贴在了公告栏。Jenkins的凭据库就是干这个的把密码、Token、密钥文件存到Jenkins里流水线通过ID引用仓库里没有秘密。凭据的创建方法是系统管理→凭据→系统→全局凭据→添加凭据。类型选“Username with password”或“SSH key”关键是记住凭据ID代码里要用。引用的写法如下pipeline { agent any environment { // DEPLOY_SSH_PASSWORD 是凭据ID运行时会被注入成变量 DEPLOY_SSH_PASSWORD credentials(deploy-ssh-password) DEPLOY_HOST 192.0.2.10 DEPLOY_USER deploy } stages { stage(Deploy) { steps { sh set -e sshpass -p ${DEPLOY_SSH_PASSWORD} ssh -o StrictHostKeyCheckingno ${DEPLOY_USER}${DEPLOY_HOST} \ systemctl stop app cp /opt/app/app.jar /opt/app/app.jar.bak sshpass -p ${DEPLOY_SSH_PASSWORD} scp target/app.jar ${DEPLOY_USER}${DEPLOY_HOST}:/opt/app/app.jar sshpass -p ${DEPLOY_SSH_PASSWORD} ssh ${DEPLOY_USER}${DEPLOY_HOST} systemctl start app } } } }逻辑说明credentials(deploy-ssh-password)会在运行时把该ID对应的密码注入到DEPLOY_SSH_PASSWORD变量里。构建日志只显示变量引用不显示实际密码这是凭据库最基本的安全收益。StrictHostKeyCheckingno是为了避免首次SSH连接时出现交互式确认把流水线卡住真正严格的环境应该把目标服务器的公钥提前写入known_hosts。参数说明凭据ID建议用环境-用途-类型这样的命名方式例如prod-ssh-password、staging-api-token。后续维护多个环境时看到ID就知道是什么。另外注意credentials()注入的变量如果包含用户名:密码格式普通密码用credentials()没问题但碰到特殊字符多的Token建议改用withCredentials块做更精确的控制。2.3 全局工具链JDK、Maven、Git与四个容易被忽略的开关全局工具配置是新手最容易忽略的一环。很多人在构建节点上手动装了JDK和Maven然后在Jenkinsfile里写死路径结果换一台Agent就报“找不到mvn”。正确做法是在“系统管理→全局工具配置”里统一声明工具链由Jenkins自己管理版本和路径。下面是四个我每次搭环境都会调的开关表格里给了推荐值配置项常见默认值我的推荐值原因执行者数量21多个Executor并发跑同一个Workspace会互相踩文件先保稳定全局工作目录/var/lib/jenkins/workspace挂载到独立数据盘系统盘容量一般小构建产物多会把根分区塞满插件更新中心https默认内网镜像或原始地址公网源不稳定内网搭建需要改镜像地址构建历史保留永久保留最近30次节省磁盘旧日志没人看还占空间逻辑说明执行者数量不是越大越好。虽然看起来“并发构建”能提升效率但在没有独立Workspace策略的情况下多个构建同时清理和写入同一个目录会引发随机失败。先调成1等后面有需要再按项目维度开并发。参数说明全局工具配置里的“自动安装”会让Jenkins去官方源下载工具内网环境经常超时。我在内网环境一般是手动下载JDK和Maven到指定目录然后在这里填路径禁止Jenkins联网下载。另外“环境变量”里要加PATH确保流水线里执行mvn、git不用写全路径。3. 用Jenkinsfile写第一条流水线最小可用版本与参数化配置环境搭好之后最关键的环节就是用Jenkinsfile定义构建过程。Pipeline是Jenkins的核心它把构建、测试、部署步骤写成一个文本文件放进代码仓库这样每次改构建逻辑都走代码评审而不是在Web界面里点来点去。这一章从选型讲到最小可用版本再讲参数化是整篇文章最值得反复看的部分。3.1 声明式Pipeline和脚本式Pipeline按团队协作方式做选择Jenkins Pipeline有两种写法声明式和脚本式。很多初学者纠结选哪个我给出一个简单标准如果你的团队多数人是后来才接触CI/CD选声明式它结构固定、可读性强报错信息也友好如果流水线里有大量的循环、条件分支、动态计算脚本式更灵活但维护成本高。对比维度声明式Pipeline脚本式Pipeline学习曲线平缓语法像配置文件陡峭本质是Groovy代码可读性高阶段清晰低逻辑与配置混在一起错误提示较明确需要自己调试Groovy适用场景大多数项目复杂动态流程、自定义扩展我的习惯是整个团队统一用声明式遇到复杂逻辑就写一个共享库函数而不是放开让大家写脚本代码。否则半年之后Jenkinsfile会变成每个人风格不同的 Groovy 拼盘谁也看不懂。3.2 最小可用Jenkinsfile从拉取代码到归档产物的一段完整流水线下面是一份我平时搭新项目时用的最小模板包含拉代码、跑测试、打包、归档四个阶段。复制到项目根目录作为Jenkinsfile然后在Jenkins里新建任务指向它即可。pipeline { agent any options { timestamps() // 日志加上时间戳排查时能分清时序 timeout(time: 20, unit: MINUTES) // 超时保护防止构建卡死占着Executor disableConcurrentBuilds() // 同一项目同时只跑一个构建避免冲突 } environment { APP_NAME order-service JAVA_HOME /usr/lib/jvm/java-17 MAVEN_HOME /opt/maven/apache-maven-3.9 } stages { stage(Checkout) { steps { checkout scm // 拉取当前分支最新代码 } } stage(Unit Test) { steps { sh mvn test // 跑单元测试失败则中断 } } stage(Build) { steps { sh mvn clean package // 打包跳过测试是因为上面已经跑过 } } stage(Archive) { steps { archiveArtifacts artifacts: target/*.jar, fingerprint: true } } } post { always { junit target/surefire-reports/*.xml // 收集测试报告红色展示在任务页 } failure { echo 构建失败请查看测试报告定位问题 } } }逻辑说明environment里设置的是环境变量供后续sh步骤调用。checkout scm是声明式Pipeline的内置行为它会根据任务配置的Git地址自动拉取对应分支不需要手写git clone。archiveArtifacts把产物归档到Jenkins Master而不是留在Agent的工作目录避免Agent清理后产物丢失。fingerprint: true用于生成指纹后面可以用它追溯某个构建产物来自哪次提交。参数说明timeout的单位是MINUTES时间长短按项目大小调整普通服务20分钟足够。mvn clean package里我没有加-DskipTests因为测试阶段已经跑过了这里重复执行也能保证打包前的代码状态与已测代码一致。如果你的项目同时产生多个jarartifacts可以写target/*.jar但要注意归档前清理dubious文件。3.3 参数化构建与触发策略版本号、目标环境和定时任务一次配好固定流程的流水线只能算半自动真正好用需要支持参数和多种触发方式。参数化构建的作用是让同一套Jenkinsfile在不同环境、不同版本间复用。我常用的是string、choice和booleanParam三种pipeline { agent any parameters { string(name: VERSION, defaultValue: 1.0.0, description: 本次发布版本号) choice(name: ENV, choices: [test, staging, prod], description: 目标环境) booleanParam(name: RUN_TEST, defaultValue: true, description: 是否执行测试阶段) } stages { stage(Prepare) { steps { echo 准备发布 ${params.VERSION} 到 ${params.ENV} } } stage(Conditional Test) { when { expression { return params.RUN_TEST } } steps { sh mvn test } } } }逻辑说明params是内置的全局对象${params.VERSION}、${params.ENV}把参数值传到阶段内部。when块做条件执行比在Groovy里写if/else更符合声明式风格。实际用到部署时这些参数会被传给发布脚本实现在不同环境发布不同版本。触发策略方面常见的有四种手动触发、定时触发、轮询SCM、Webhook触发。定时任务用triggers { cron(H 2 * * *) }表示每天凌晨两点左右跑一次注意H是Jenkins的哈希值用来分散负载。Webhook触发适合代码仓库在内网的场景配置好钩子后每次push会自动触发构建但需要在Jenkins里设置token防止外部乱调。需要特别说明的是cron与pollSCM的区别。cron是到点就构建不管代码有没有变化pollSCM是Jenkins定期去仓库看有没有新提交有变化才构建。如果是想让“提交代码自动触发构建”正确方式是Webhook而不是cron。还有一个很容易忽略的坑定时任务默认不会自动清理历史构建长时间跑下来磁盘会慢慢变满配合第2章的构建历史保留策略一起设置。4. 部署到服务器脚本放置位置、环境参数与发布闸门流水线跑到“构建产物归档”这一步只是半个持续集成。真正落到目标服务器才是持续部署。很多团队的Jenkins停在“能出包”的阶段部署依然靠人手动scp到服务器这就失去了自动化的意义。这一章讲部署脚本放在哪里、环境参数怎么管以及如何加一道人工审核的闸门。4.1 部署动作放哪独立发布脚本加上下游调用比在流水线里写ssh更稳部署动作有两种常见写法第一种是把scp和ssh命令直接写在Jenkinsfile里第二种是把部署动作写成独立的shell脚本放进应用仓库或运维仓库Jenkinsfile里只负责调用它。我强烈推荐第二种。对比维度部署逻辑写在Jenkinsfile独立部署脚本调试便利性每次调试都要跑一遍流水线可以在服务器上单独执行验证复用性换CI工具则全部重写脚本独立可用于其他工具权限控制凭据暴露面较大脚本只需执行权限维护边界构建与部署耦合构建归构建部署归部署一个独立的deploy.sh大致长这样#!/usr/bin/env bash set -euo pipefail # 参数应用名、目标环境、jar包路径 APP_NAME${1:-app} ENV${2:-test} JAR_FILE${3:-target/app.jar} DEPLOY_DIR/opt/${APP_NAME} BACKUP_DIR${DEPLOY_DIR}/backup echo 开始部署 ${APP_NAME} 到 ${ENV} 环境 systemctl stop ${APP_NAME} # 清理旧备份保留最近两个版本 mkdir -p ${BACKUP_DIR} if [ -f ${DEPLOY_DIR}/${APP_NAME}.jar ]; then mv ${DEPLOY_DIR}/${APP_NAME}.jar ${BACKUP_DIR}/${APP_NAME}-$(date %Y%m%d%H%M%S).jar ls -t ${BACKUP_DIR}/*.jar | tail -n 3 | xargs rm -f fi cp ${JAR_FILE} ${DEPLOY_DIR}/${APP_NAME}.jar systemctl start ${APP_NAME} echo 部署完成逻辑说明set -euo pipefail让脚本在出现任何错误或未定义变量时立即退出避免半成品部署被误判成功。先停服再替换jar再启动这是Java应用最常见的平滑切换方式。备份只保留最近两个版本防止备份目录无限膨胀。参数说明脚本的三个参数分别是应用名、环境和产物路径流水线里通过参数传过来。这样同一个脚本可以同时给test、staging、prod三个环境用只是传入的ENV不同。Jenkinsfile里调用它的地方就变成了一个简单的sh步骤本质上比直接在流水线里写一长串ssh命令干净得多。4.2 环境信息不硬编码用参数表和配置文件管理测试、预发、生产部署脚本里最忌讳把IP、端口、用户名写死在代码里。环境一多改一处漏一处最后发布错了环境要找半天原因。我的做法是把环境信息集中到一个配置目录里每个环境一个文件部署脚本按参数读取对应文件。# 配置文件示例config/test.conf DEPLOY_HOST192.0.2.20 DEPLOY_USERdeploy APP_PORT8080 JVM_HEAP-Xms256m -Xmx1024m# 脚本中读取配置的片段 source config/${ENV}.conf echo 目标主机: ${DEPLOY_HOST}:${APP_PORT}逻辑说明source命令把配置文件中的变量导入当前shell环境后续所有命令都能直接使用。这样新增环境只需要新建一个conf文件不需要改脚本逻辑也不会把不同环境的配置混在一个文件里改乱。环境主机地址JVM堆内存端口备注test192.0.2.20256m~1024m8080开发自测每日构建staging192.0.2.30512m~1024m8080与生产同配置prod192.0.2.401g~2g8080人工审批后发布参数说明配置文件的命名与ENV参数强一致Jenkinsfile里不允许出现具体IP。这样可以保证同一个流水线在test环境验证过之后切到prod只是换个参数执行的动作是同一套逻辑不会出现“测试环境手写命令生产环境忘改IP”的低级事故。4.3 发布闸门与回滚input人工确认和备份还原的工程实践持续部署不等于“全自动发布生产”。我见过很多团队把生产也做成全自动结果一次误触发直接导致线上故障。合理的做法是非生产环境可以全自动流转生产环境加一道人工确认闸门。用声明式Pipeline的input指令实现stage(Pre Prod Check) { when { environment name: ENV, value: prod } steps { input message: 确认发布到生产环境本次版本${params.VERSION}, ok: 开始生产发布, parameters: [ booleanParam(defaultValue: false, name: confirm, description: 我已确认操作时间窗) ] } }逻辑说明input会让流水线暂停等待人工点击确认。点击后流水线继续点击中止则发布中断。when限定了只有ENVprod才会出现这个阶段测试环境发布不会受打扰。回滚也是部署里绕不开的话题。部署脚本里做了备份回滚动作就很简单在脚本中加一个rollback参数分支if [ ${1} rollback ]; then ROLLBACK_JAR$(ls -t ${BACKUP_DIR}/*.jar | head -1) cp ${ROLLBACK_JAR} ${DEPLOY_DIR}/${APP_NAME}.jar systemctl start ${APP_NAME} exit 0 fi逻辑说明回滚的本质是找到最近一次备份并恢复。ls -t按时间倒序排列head -1取最新备份。这里需要注意如果部署后应用运行了一段时间才被发现异常最新备份可能已经是坏版本回滚的目标应该是更早的备份。因此备份保留数量不要只留一个建议像前面脚本那样保留最近三个左右。参数说明生产发布时Jenkinsfile里建议把confirm参数设成“必须勾选才能继续”比单纯的点击按钮多一层显式确认。另外input有一个缺点如果没人点它会一直卡在队列里占用Executor。配合第2章建议的timeout设置给整个流水线加超时防止周五下班忘记确认周一回来卡死所有构建。5. 避坑手册Jenkins持续交付里最常见的五个故障排查记录Jenkins用的时间越长越会发现很多问题不是技术复杂而是细节没做好。我整理了自己踩过和帮同事排过的五个高频故障按“现象→原因→解决”的方式记录。每条都有明确的排查入口比在网上翻半天答案高效。5.1 测试环境偶发拿到旧包构建历史看起来却全绿现象流水线显示成功测试人员说测试环境跑的还是上个版本的功能。回看构建日志打包时间确实是新的但目标服务器上的jar始终是旧时间戳。原因最常见的是构建节点和目标服务器存在多个目录发布脚本读取的jar路径配置串了或者agent上Workspace清理不干净旧文件被残留备份重新拷贝覆盖。更隐蔽的情况是服务器时间不对文件时间戳看起来旧实际内容已更新。解决第一步登录目标服务器检查实际运行的jar路径和启动命令里的路径是否一致用realpath查看软链接目标。第二步在发布脚本里增加版本校验部署前读取jar包内的META-INF/MANIFEST.MF并打印部署后再校验一次。第三步确认目标服务器用NTP同步时间避免时间漂移导致日志与构建时间对不上。5.2 日志里的中文全变乱码测试报告文件名也跟着乱现象构建日志里的中文显示成??或乱码JUnit测试报告里带中文用例名全丢看不了失败详情。原因Jenkins自身编码不是UTF-8或者Agent节点上的文件编码与Master不一致。很多项目在Windows或GBK编码环境下写代码Maven打包时未指定编码默认用了系统编码。解决在启动Jenkins的JVM参数里显式指定-Dfile.encodingUTF-8同时把Maven的pom.xml里project.build.sourceEncoding设为UTF-8。更保险的做法是在Jenkinsfile的构建命令前加一句export JAVA_TOOL_OPTIONS-Dfile.encodingUTF-8确保子进程也继承相同编码。改完之后清掉历史构建重新跑一次验证老日志不需要管。5.3 服务器重启后构建队列卡住定时任务反复排队现象一台Agent重启之后Jenkins上的构建任务开始排队不执行点进去显示“Waiting for next available executor”甚至多次重启后任务越积越多。原因Agent断开后Jenkins没有自动清理掉旧的Executor记录导致节点状态显示在线但实际连接已断开。定时任务设置的并发锁还占着新的构建进不来。解决节点管理里把该Agent标记为“断开”等待Jenkins释放Executor之后重新连接。同时给Jenkinsfile加上disableConcurrentBuilds()和timeout防止一个挂死的构建永久占坑。长期维护建议给Agent配置进程守护并开启Jenkins的“节点离线自动恢复”相关配置减少人工介入。5.4 内网环境依赖下载超时Maven构建频繁失败现象构建报错Could not transfer artifact ... Connection timed out多台机器随机失败增量构建偶尔能过全量构建必挂。原因Maven仓库配置默认指向公网中央仓库内网出口带宽不稳定传大jar包时连接超时。还有可能是某个插件或依赖只存在于特定仓库没配置镜像源。解决在内网搭建Maven私服设置settings.xml的mirrorOf为central让所有中央仓库请求走本地镜像。如果暂时没有私服临时方案是在Jenkins的MAVEN_OPTS里加上超时参数并开启重试机制但这不是长久之计。还要注意私服配置不要只放在Jenkins这台机器上开发者本地也要同步否则会出现“Jenkins能构建、本地构建失败”的奇怪现象。5.5 并发构建互相污染Workspace残留让构建时好时坏现象同一个项目单独构建每次都成功两个构建同时跑就出现随机编译报错。更奇怪的是有时候改了代码却不生效构建产物里混着旧内容。原因多个Executor共享同一个Workspace目录并行构建时一个在清理另一个在写文件互相踩踏。另外构建完成后没有清理Workspace下一次构建开始时目录里还残留着上一次的class文件增量编译时没用新代码。解决项目级加上disableConcurrentBuilds()彻底禁掉同一项目的并发。在Jenkinsfile的post里增加cleanWs()清理工作区或者用deleteDir()。如果团队确实需要并发为每个分支配置独立的Workspace用String BUILD_TAG区分目录。这里有一个血泪经验无论哪种方案发布前的最终构建请不要开启增量编译打包阶段用mvn clean package保证产物是全新的。6. 进阶习惯用构建指纹和发布检核把一次发布压到三次点击前面几章解决了“怎么搭、怎么写、怎么避坑”最后一章讲怎么验证这套机制真的可靠。很多团队的流水线看起来绿油油真到发版还是手忙脚乱原因是没有建立“发布信任”。我给一个具体方法让一次发布只靠Jenkins界面三次点击完成并且每次都要能看到本次发布对应的源码提交。6.1 用构建指纹核对每次发布对应的源码提交在Jenkinsfile里开启fingerprint: true之后每次构建产物会生成一个指纹指纹里记录了产物来自哪次提交、被哪个构建使用过。发布之后我一般会打开产物的指纹页面确认它对应的上游提交号与代码仓库里合并到主干的最新提交一致。这一步是发布前的核心核对项比看一眼“构建成功”四个字可靠得多。配合指纹在流水线里把提交号写进产物名也是一个好习惯。例如归档命名用${APP_NAME}-${params.VERSION}-${GIT_COMMIT_SHORT}.jar这样传到服务器上光看文件名就能知道是哪个版本哪次提交排查问题时不需要翻Jenkins历史。Git插件会提供GIT_COMMIT环境变量取前七位作为短提交号environment { COMMIT_SHORT sh(script: git rev-parse --short HEAD, returnStdout: true).trim() br / APP_ARTIFACT ${APP_NAME}-${params.VERSION}-${COMMIT_SHORT}.jar }6.2 给自己定一个“只靠界面完成一次发布”的验证习惯我自己的习惯是每个迭代挑一次发布全程只在Jenkins的Web界面操作不打开终端。流程是固定的先点开构建历史确认本次发布触发了对应分支的构建再检查指纹确认提交号正确然后跑一遍非生产环境的流水线确认测试、打包、部署三个阶段都完成最后走到生产环境的input闸门核对版本号和确认勾选框点击开始发布。发布完成后再回到指纹页面看生产服务器上记录的指纹是否与本次构建产物匹配。这套流程第一次跑通常会暴露不少问题可能有某个环境没接流水线可能有人绕过了闸门手动部署也可能构建产物根本没被生产服务器使用。把这些洞都补上之后发布就成了一个大多数时候不需要人盯着的动作。我见过一个内部项目从“发版当天全员在线盯群”变成“发布只需要一个值班人点三次按钮”靠的不是更复杂的自动化平台而是把这套Jenkins持续集成与部署的链路做扎实并养成了每次发布都验证指纹的习惯。希望这篇实战笔记能帮你少走几个弯路也希望你能尽早体验那种“点了开始发布之后可以安心去接杯水”的踏实感。本文还有配套的精品资源点击获取