★ FEATURED ARTICLE 我最早接触持续集成工具就是因为被一次手动发版折磨到天亮。那次经历让我下定决心必须把构建、测试、部署这套流程彻底自动化。而聊到持续集成工具Jenkins 几乎是绕不开的名字。这篇文章我就结合自己部署 Jenkins 的完整过程把从环境准备、安装配置到流水线搭建的每个环节包括踩过的坑和处理方案原原本本写出来。项目标题是“持续集成工具-Jenkins的部署流程”那我们就从最实际的问题开始Jenkins 到底怎么部署部署完该怎么用才能让持续集成真正跑起来。这套内容适合刚接手 CI 建设、准备在团队里落地自动化构建的开发者也适合那些已经把 Jenkins 跑起来但总出问题、想搞清楚原理的运维同学。我会尽量少讲空泛概念多给能直接照做的步骤和参数。1. 先把持续集成这件事想清楚1.1 持续集成到底解决了什么问题在聊 Jenkins 部署之前得先明确一个前提持续集成Continuous IntegrationCI不是装个工具就完事它是一套工程实践。核心思想是频繁地把代码变更合并到主干每次合并都自动触发构建和测试尽早暴露集成问题。举个例子。没有 CI 的时候团队几个人各自开发代码合并集中在发版前。结果就是A 改的接口把 B 的调用弄挂了C 加的依赖和 D 用的版本冲突这些问题全在发版窗口集中爆发修一个冒一个。引入 CI 之后每次代码推送到远端自动触发编译、跑单测有问题当场就发现定位成本低得多。需要说明的是CI 不等于 CD持续交付/持续部署。CI 侧重“提交代码后自动验证”CD 侧重“验证通过后自动交付到环境”。Jenkins 两者都能做但我个人建议先专注 CI把构建和测试做扎实再考虑自动部署。1.2 Jenkins 凭什么成为首选工具持续集成工具不少市面上有 GitLab CI、GitHub Actions、Travis CI还有云厂商自带的各种流水线服务。但 Jenkins 在自建场景下依然有不可替代的位置。第一插件生态太丰富了。从代码拉取、编译构建、测试报告展示到钉钉/邮件通知几乎你能想到的环节都有插件支持。我统计过我这边生产环境用的插件常年保持在 30 个左右覆盖了多语言构建、凭证管理、Kubernetes 集成整个链路都很顺。第二完全自托管。代码仓库是内网的或者需要访问内网私有化环境的Jenkins 部署在公司内网最省事。相比 SaaS 服务数据不出内网合规问题也少。第三Pipeline 能力强。Jenkins 的 Pipeline 用代码定义整个构建流程可以做成 Jenkinsfile 放进代码库这样构建逻辑跟着项目走谁改了都看得见回滚也方便。当然选型也不是非它不可。如果团队规模小、代码量不大且仓库托管在某个代码托管平台上用平台自带的 CI 功能会更快。但如果你需要一个长期稳定、可控性强的方案Jenkins 依然是自建 CI/CD 基础设施中很扎实的选择。2. 部署前的环境评估与版本选型2.1 硬件与操作系统选型建议部署 Jenkins 之前先把运行环境定下来。我踩过的一个最直接的坑就是低估了资源需求。Jenkins 本体是个 Java Web 应用占用内存不大但任务并发起来之后尤其是要同时构建多个项目时内存和 CPU 消耗涨得很快。我建议最低配置2 核 CPU、4GB 内存、40GB 以上可用磁盘。如果你们还要在 Jenkins 上跑编译、跑镜像构建这类重活那最好 4 核 8GB 起步。磁盘要留足因为构建产物、插件、日志都会持续增长后期可以靠定期清理策略控制但初期空间别太抠。操作系统方面我推荐用某个长期维护的 Linux 发行版。Windows 和 macOS 也能装但生产环境不推荐原因很简单Linux 环境下做脚本调试、权限管理和 Docker 集成都更顺手。我这里演示用的是 Linux 的环境具体发行版大家按自己熟悉的来。2.2 JDK 与 Jenkins 版本的配对策略Jenkins 是 Java 应用JDK 版本必须匹配。这里有个非常关键的细节不同版本的 Jenkins 对 Java 版本的要求不同。以我部署时的情况为例当时的 Jenkins 版本要求 JDK 17 或更新版本。如果你用的是老一点的 Jenkins 版本可能只支持 JDK 8 或 JDK 11。装之前先去官网查一下版本兼容矩阵别装完发现 Jenkins 启动不了。安装 JDK 时还有个小细节尽量用发行版仓库里的包或者用某厂商的官方 JDK 发行版。有些公版脚本会默认装一个版本路径还不一定对后面排查起来很麻烦。装完用 java -version 确认版本没问题再进入下一步。注意Jenkins 安装程序自带的 setup 向导会检测 Java 环境检测不通过会直接报错。提前确认java -version输出符合要求能省很多事。3. 安装部署全流程实操3.1 基于安装包的常规部署步骤部署方式上我优先推荐用发行版的软件仓库安装 Jenkins。这样做的最大好处是后续升级方便Jenkins 出新版本直接执行包管理器升级命令就能完成插件和新功能也能及时跟上。第一步添加官方软件源。这步很关键如果不添加源直接用系统的默认源装版本会非常老容易出现兼容性问题。不同发行版添加源的方式不同大概是导入官方的 GPG 密钥然后把 Jenkins 的仓库地址写进源列表最后刷新源缓存。这个流程做完之后再安装。第二步安装。包管理器会自动把 Jenkins 依赖的组件拉下来。装完检查一下服务状态是否正常运行。如果遇到启动失败多半是 JDK 版本不对回到上一节重新核对。第三步防火墙放行。Jenkins 默认监听 8080 端口你需要确保这个端口可访问。如果是内网机器且大家都用跳板机那防火墙规则自己按需调整。然后就可以通过http://服务器IP:8080访问了。首次访问会要求输入一个初始密码这个密码在服务器上有明确的文件路径取出来填进去就行。3.2 基于 Docker 的容器化部署方案如果你的团队已经在用容器或者希望 Jenkins 实例能快速迁移和重建那用 Docker 部署也是不错的方案。这里我简单说一下思路不展开具体命令因为不同环境差异较大。用 Docker 部署 Jenkins 一个大坑是权限问题。Jenkins 容器里的用户不是 root如果要挂载宿主机的 Docker 套接字来实现“容器内构建再生成容器”的方案必须处理好用户 ID 和权限映射否则会一直报权限不足。我的建议是如果只是验证功能用 Docker 跑一个临时实例没问题如果要做生产级部署优先用安装包方式控制面更简单排查问题也更直接。容器化虽然灵活但引入了额外的存储、网络、权限维度的问题初期容易劝退。3.3 初始化配置与插件安装策略首次登录后Jenkins 会让你选择安装插件的方式。推荐的选项是“Install suggested plugins”也就是安装官方推荐插件。这个组合稳定覆盖面也够适合多数场景。但如果你明确知道自己不需要某些插件也可以选择自由选择安装。我个人建议先装推荐的跑通流程之后再按需增减。这一步追求的是快速可用的初始状态。初始化时还会要求创建管理员账号。这里有个容易忽略的问题初始密码在首次登录后可以用但创建完管理员账号后后续登录就用新账号了。如果之后想给别人开账号需要在系统管理里配置用户权限。加载插件的速度有时会比较慢特别是需要访问外网才能下载插件的场景。建议在系统配置里改一下插件更新中心地址换成国内可访问的镜像源速度会明显改善。这一步具体地址各环境不同但我建议大家都提前确认一下是部署流畅度的重要影响因素。4. 第一个自动化构建任务的完整配置4.1 构建任务的核心三要素拆解初始化完成后我们来创建一个实际可用的构建任务。以我之前部署时用的模拟项目 X 为例这是一个常规的 Web 项目代码托管在内网的 Git 仓库里。在 Jenkins 里创建任务时建议选择“自由风格”来入门。一个自由风格任务离不开三个要素源码管理、构建触发器、构建步骤。源码管理这块选 Git然后把仓库地址和凭证填进去。凭证可以先用用户名密码方式后续再升级成部署密钥。需要注意分支配置默认是*/master如果你的默认分支是 main一定要改过来。构建触发器决定了什么时候跑。常用的触发方式有三种定时轮询代码仓库、Webhook 触发、以及上游任务触发。Webhook 是体验最好的方式代码一推就触发不用等轮询。但设置 Webhook 需要代码仓库平台能访问到 Jenkins 地址内网环境通常没问题外网就需要做端口映射。构建步骤是最有文章的地方。对于 Java 项目可以加一个 Maven 构建步骤执行 clean package 命令来产出编译包。这一步建议加上单元测试的闸门测试不通过就直接失败避免坏代码往下流。4.2 参数化构建与构建后动作实际使用中你会发现固定不变的构建流程太少。很多时候要区分测试环境和正式环境要能手动指定版本号要选择只跑某项测试。这时候就需要参数化构建。在任务配置里勾选“参数化构建过程”添加字符参数、选项参数或布尔参数。比如我加一个BRANCH_NAME参数构建时就能临时指定要构建的分支。构建步骤里的 Git 分支就用${BRANCH_NAME}这个变量来引用。这样同一个任务既能跑最新代码也能用来补发历史版本。构建后动作也别忽略。最基础的是构建结果通知可以邮件通知也可以推到即时通讯工具。另外强烈建议把构建产物归档配置上这样每次构建后在任务页面就能直接下载 war 包或 jar 包排查问题不用再到服务器上翻目录。4.3 凭证管理与敏感信息处理第一次配置 Git 密码的人很容易直接把密码明文填在任务里。这样做短期方便但后患无穷任务配置页在浏览器里任何能看到页面的人都能看到密码多人协作后密码改动又要跑到每个任务里去更新极其痛苦。正确做法是在系统配置中先创建“凭证”把用户名密码或部署密钥存进去然后在任务里引用这个凭证 ID。这样做的好处是密码只存一份更换时不用逐个任务去改。还有一个细节如果在构建脚本里需要用到私有源或者镜像仓库密码不要直接硬编码。可以在参数化构建的变量里引用或者用凭证绑定插件在构建时动态注入环境变量。Jenkins 对这个场景支持得不错关键是要养成敏感信息全部走凭证管理的习惯而不是图省事。5. 从自由风格任务到流水线的持续集成升级5.1 为什么要用 Pipeline 替代多条自由风格任务用了一段时间的自由风格任务后你会感受到它的局限。最明显的问题是流程散落在各个任务的配置页里没法直观看到整个链路。比如 commit 触发构建构建完要手动去点部署或者靠多个任务之间的上下游关系串联出了问题时很难定位是哪一段的问题。Pipeline 把整个流程用脚本描述出来从拉代码、编译、测试、镜像构建到推送制品、部署到某环境一条流程清晰可见。你可以直观看到当前卡在哪一步每步日志也独立分段排查效率高很多。我这里强烈建议如果团队流程已经开始复杂化尽早转到 Pipeline 上。虽然写 Jenkinsfile 比在界面上点配置要多学一点 Groovy 语法但这个学习成本是必要的。更重要的是Jenkinsfile 是代码像项目源码一样维护代码评审和变更记录都有了这才是工程化。5.2 一个可复用的多阶段流水线示例分享一个我实际用过的流水线骨架拿来做参考非常合适。整个流程大概四个 stage拉取代码、构建与单测、产出镜像并推送、按参数决定是否部署。拉取代码阶段直接用 checkout 步骤分支从参数里读这样手动构建时可以指定分支。构建与单测阶段用 Maven 或前端构建工具跑编译然后归档测试报告。如果用了 GitLab 这类平台还可以假装测试报告读回去。镜像构建和推送阶段基础是构建产物已经准备好。这里会用到 Docker 的构建能力建议把镜像仓库地址和凭证做成环境变量避免写死在 Jenkinsfile 里。镜像 tag 可以用构建号加上 Git 短 commit hash 拼接保证可追溯。这个 tag 命名习惯非常重要后期回溯线上版本全靠它。部署阶段如果只是测试环境可以直接在 Jenkins 机器上执行脚本或者调用远端宿主机的部署接口。生产环境我建议加入人工确认步骤用 input 指令卡一下等有权限的人点击“继续”才执行后续操作。初次尝试时这个门槛能挡住很多误操作。5.3 多分支流水线与分支策略匹配当你把 Jenkinsfile 提交到代码库之后你会发现“多分支流水线”这个功能特别香。它会自动扫描仓库里的所有分支每个分支都能有独立的构建记录和状态展示保护分支额外设置超时与告警。这与团队的 Git 工作流直接关联。如果你们做主分支开发模式那每次合并到主干都会自动触发构建和测试如果做 Git Flow那 release 分支要额外跑一遍完整测试和部署到预发环境。这些策略都靠多分支流水线来落地每个分支类型用不同的构建参数和发布目标。我实际用下来的体会是分支策略不用复杂但要明确“哪类分支触发哪类构建”。这一条在 Jenkinsfile 里用 when 条件就能实现不用维护一大堆任务配置清晰多了。6. 高频问题排查与避坑实录6.1 部署和日常使用中的高频故障速查我把这些年遇到过的高频问题按现象、原因、解决方案整理成一个表方便你在出问题时直接对照。问题现象常见原因处理思路启动失败日志提示 Java 版本不支持JDK 版本与当前 Jenkins 版本不兼容查版本兼容矩阵更换 JDK 版本插件安装极慢或超时默认插件中心地址访问受限更换为可用的镜像源再做一次插件更新构建任务一直卡在拉取代码凭证无效或机器人不允许访问仓库检查凭证有效期用部署密钥替换密码Git 拉取失败提示临时文件目录不可写工作空间目录权限不对检查 Jenkins 进程用户的目录写权限构建产物找不到步骤里没配置归档或产物路径不对确认构建结果的相对路径并勾选归档Webhook 不触发构建出口 IP 限制、地址不通或凭证不匹配在仓库端手动测试 hook检查消息记录定时任务到了时间不执行时区配置错误服务器时区与预期不符修改 JVM 时区为指定的本地时区构建历史丢失页面报空间不足磁盘占用超过阈值清理旧的构建记录和日志设置保留策略这张表涵盖了我最常遇到的几类问题。其中“构建历史丢失”这个现象初期我以为是 Jenkins 的 bug后来排查发现是磁盘满了系统自动清理了部分旧数据。磁盘空间监测对 Jenkins 来说真的很重要建议直接配置系统监控插件空间低于阈值主动告警。6.2 并发构建与权限控制的一些心得Jenkins 默认是支持并发构建的但并发度过高会直接拖垮机器。我遇到过一台 4 核 8GB 的机器上同时跑 6 个构建任务每个都是前端编译加单测结果内存直接打满构建大面积失败。后来给主节点设置了最大并发构建数限制才算稳定下来。并发控制还有一个容易被忽视的维度多个任务同时写同一个代码目录或者同时操作同一个输出路径会产生不可预期的构建结果。我后来把所有构建任务都配置成“不允许并行执行”也就是使用自定义工作空间把每个项目的构建目录完全隔离。虽然牺牲了一点并发度但换来的是构建结果的确定性。权限方面我推荐一开始就启用 Jenkins 自带的基于角色的权限控制。团队规模小的时候可能感觉不到一旦加了新人或需要外部同事看构建日志没有权限隔离就会很尴尬。我吃过这个亏一个临时同事进来帮忙看问题顺手就动了一个生产部署任务的配置虽然没有造成事故但彻底改变了我对 Jenkins 权限管理的态度。提示Jenkins 默认是“任何人都可以操作所有任务”的模式这在开发环境无所谓只要你们的环境涉及生产部署操作就一定要做权限隔离。好的权限模型是“按角色分场景”开发角色只能触发构建和查看日志运维角色才有权限改配置和执行部署。6.3 多环境发布的一个稳定实践Jenkins 部署还有一个进阶问题怎么用一套流程管理开发、测试、预发、生产多个环境的发布。我的做法是用参数化构建区分环境每个环境对应的目标主机列表、配置文件模板不一样。在 Jenkinsfile 中可以定义一个环境分支的判断然后根据参数选择不同的部署目标。这里有一个很关键的细节构建产物应该只构建一次然后多次部署。不要在每个环境都重新编译一遍那样既有性能损耗又可能因为环境差异产生出不同产物。正确做法是构建阶段统一产出制品部署阶段按不同环境参数拉取同一物件的不同配置。这套模式帮我解决了很大的维护成本。以前每个环境都要维护一套任务现在核心流程就一条环境差异只体现在参数和配置里加一个环境基本是几分钟的事。写在最后一次部署带来的长期收益从第一台 Jenkins 部署到现在我最深的体会是工具本身不难难的是想清楚你要把它用成什么样。很多人装 Jenkins 只是为了“有个持续集成工具”结果装完没人维护任务三天两头挂最后反而不如手动构建稳当。Jenkins 部署只是一个开始。它能发挥多大价值取决于你愿不愿意把构建、测试、制品管理这些环节都接入进来。我建议第一周先只做一个项目的编译加单测跑稳了再加镜像构建再加自动部署到测试环境一步步来别贪多。等整套流程真正转起来你会发现之前手动发版的那些担惊受怕都会变成一次很轻松的流水线操作。
阅读完成 · 觉得有帮助？
