很多第一次搭持续集成环境的同学都会卡在同一个问题上Git、Maven、Jenkins 三样东西单独都能跑通但一旦要把它们串成一条自动化流水线就会在各个接口处断掉。比如 Jenkins 拉取了代码却找不到 MavenMaven 装好了构建时又提示 JDK 版本不对好不容易构建成功又不知道产物该往哪里放。这个断点本质上不是工具装得少而是脑中没有一张完整的工作流程图。本文要做的事很直接先讲清楚 Jenkins 的工作流程再把 Git 和 Maven 在这套流程里的安装、配置和联动方式一步步落地最后用一个 Pipeline 示例跑通“拉取代码 → Maven 编译打包 → 部署到服务器”的完整链路。操作环境以 CentOS 7 为例读者如果是 Ubuntu 或 macOS把包管理器命令换成对应的即可整体思路完全通用。如果你正在负责一个小团队的持续集成环境搭建或者被“本地能构建、Jenkins 上就失败”这个问题困扰这篇文章可以直接当操作手册来用。1. 为什么 Jenkins 工作流离不开 Git 和 Maven1.1 一次 CI/CD 中的三个关键角色在开始安装之前先建立三个角色的基本认知后面所有操作都会围绕它们展开。Git 是代码仓库工具负责管理源码的版本和分支。Jenkins 构建时首先要从 Git 仓库拉取指定分支的代码所以 Git 不是只在开发者本地发挥作用它同时也是 Jenkins 的服务端依赖。Jenkins 所在机器必须安装 git 命令才能在构建任务里执行 checkout、clone 这类操作。Maven 是 Java 项目的构建工具核心作用有两个一是依赖管理pom.xml 里声明了十几个甚至几十个依赖Maven 负责把它们下载下来并放到统一仓库二是构建打包执行mvn clean install可以把源码编译成可运行的 jar 包或 war 包。在持续集成场景里Maven 是“把源码变成部署产物”的关键一环。Jenkins 是中间的编排引擎。它本身不写代码、不编译代码它的职责是触发构建、调度构建、展示构建结果。可以把 Jenkins 理解成流水线上的总控台Git 是原料入口Maven 是加工车间Jenkins 负责在正确的时机调用它们。这三个角色在一条流程中各自独立却又严格依赖先后顺序。很多新手的问题在于只把 Jenkins 当作一个 Web 管理界面来装忽略了它底层还需要依赖 Git 和 Maven 的命令行程序。1.2 从零搭建 Jenkins 最容易卡住的三个环节根据社区里大量踩坑案例从零搭建这套环境通常会卡在三个环节。第一Git 拉不到代码。Jenkins 任务配置了 Git 仓库地址但构建时提示认证失败或者找不到代码。这通常不是 Jenkins 的问题而是服务器本机没有配置 Git 免密或者没有在 Jenkins 中保存可用的凭据。第二Maven 没有被 Jenkins 找到。构建时控制台报mvn: command not found。这是因为 Jenkins 启动时不会自动加载系统的/etc/profile环境变量你明明在终端里执行过mvn -v但 Jenkins 依然找不到 Maven。正确的做法不是在服务器上装完就算结束而是要进入 Jenkins 的全局工具配置里显式指定 Maven 的安装路径。第三依赖下载慢到无法接受。Maven 默认下载依赖走的是中央仓库网络状况不好时构建可能卡在依赖下载阶段。配好国内镜像仓库后构建速度会有一个质的变化。理解这三个环节就理解了这篇文章后半部分为什么要反复强调“全局工具配置”和“镜像仓库配置”。2. Jenkins 工作流程拆解从代码提交到自动部署2.1 一次完整构建经历的阶段Jenkins 的自动化构建可以用下面这个文字流程来描述。脑子里有了这张图再回看各种配置项就不会觉得它们是一堆孤立的按钮。代码提交Git → 触发构建Webhook 通知 / 定时轮询 / 手动触发 → Jenkins 工作空间拉取代码git checkout → Maven 解析 pom.xml 并下载依赖 → Maven 编译并执行单元测试 → Maven 打包生成 jar / war 产物 → 脚本推送产物到目标服务器scp / rsync / docker build → 邮件或飞书通知构建结果这个流程最典型地体现了持续集成的基本思想每一次代码提交都有机会触发一次完整的构建验证。如果编译失败或测试不通过问题在提交早期就被发现而不是等到上线前才集中爆发。从 Jenkins 的角度看这个流程被分成三个逻辑模块源码管理模块负责和 Git 打交道构建环境模块负责调用 Maven 和 JDK构建后操作模块负责处理产物分发与通知。后面配置 Jenkins 任务时所有配置项都会落在这三个模块中。2.2 Freestyle Job 与 Pipeline 两种实现方式在 Jenkins 里落实上面这套流程有两种主流方式。第一种是 Freestyle Job也就是自由风格任务。操作方式是在 Web 界面上填写源码地址、构建命令、构建后操作适合快速验证环境是否打通。第二种是 Pipeline也就是流水线。它用 Groovy 语法把整个流程写成一个 Jenkinsfile可以随代码库一起做版本管理。对于团队项目强烈推荐使用 Pipeline。原因很简单Freestyle Job 的配置散落在 Jenkins 界面上改一次就要重新点击多个页面而且无法把这些配置放进 Git 仓库做 reviewPipeline 则是把“构建流程”本身当成代码来管理每次改动都有记录可以回滚也更容易在不同 Jenkins 实例之间迁移。这篇文章后面的实战示例采用 Pipeline 方式。理解了两种方式的差异你在团队推进时至少不会选错方向。3. 环境准备与安装方式选型3.1 服务器环境要求先看硬件和操作系统。Jenkins 本身是 Java 应用占用内存主要看构建任务的并发量。如果只是搭建学习环境2 核 4 G 的云服务器完全够用如果团队并发构建较多建议至少 4 核 8 G。操作系统方面本文以 CentOS 7 为例。无论使用云服务器还是虚拟机都建议先确保系统可以正常访问外网因为 Jenkins 插件下载、Maven 依赖下载都需要网络连接。还需要注意服务器的防火墙策略。Jenkins 默认监听 8080 端口如果从外部浏览器访问要确保安全组和系统防火墙都放行了该端口。CentOS 7 下可以用以下命令检查firewall-cmd --list-ports如果 8080 端口不在列表中执行放行firewall-cmd --add-port8080/tcp --permanent firewall-cmd --reload3.2 Java 环境准备Jenkins 是用 Java 写的安装前必须确认机器上有可用的 JDK。新版 Jenkins 对 JDK 版本有要求一般建议使用 Java 11 或 Java 17具体以你下载的 Jenkins 版本的官方文档为准。在 CentOS 7 上可以通过 yum 安装yum install -y java-11-openjdk java -version执行java -version能正常输出版本信息就说明 JDK 就绪。这里要区分一个概念这台机器上安装的 JDK 不仅服务于 Jenkins 本身还会用于 Maven 编译 Java 项目。所以如果项目需要 JDK 8而 Jenkins 要求 JDK 17最简单的方式是安装多个 JDK在 Jenkins 全局工具配置里分别指定。这个后面会详细说明。3.3 三种部署方式对比安装 Jenkins 的常见方式有三种不同场景选择不同。部署方式优点缺点适用场景war 包 Java 直接启动升级替换文件即可结构简单需要自己管理进程和开机自启单机快速部署、学习环境系统服务方式yum/rpm自动注册服务支持 systemctl 管理目录结构分散定制性稍差生产环境标准部署Docker 方式环境隔离、迁移方便需要额外维护容器和挂载卷已有容器化基础设施的团队对于初学者本文推荐 war 包方式因为它最能直观看到 Jenkins 的目录结构和日志输出排查问题时心智负担最小。等你熟悉了这套机制再去切换成系统服务或 Docker 都是很容易的事。4. 安装并初始化 Jenkins4.1 使用 war 包启动 Jenkins打开终端创建目录并下载 Jenkins LTS 版本的 war 包mkdir -p /opt/jenkins cd /opt/jenkins wget https://get.jenkins.io/war-stable/latest/jenkins.war下载完成后用 Java 直接启动java -jar jenkins.war --httpPort8080首次启动时Jenkins 会在当前用户目录下创建 JENKINS_HOME默认路径是/root/.jenkins。这里要留意磁盘空间因为插件和构建记录都会存放在这个目录下。启动过程中终端会输出大量日志看到类似Jenkins is fully up and running的提示就表示启动成功。如果服务器内存较小可以加上 JVM 参数限制内存java -Xms512m -Xmx2048m -jar jenkins.war --httpPort8080这个命令手动启动的方式在终端关闭后会停止想长期运行建议配合nohup或者注册成 systemd 服务。4.2 完成初始化配置浏览器访问http://服务器IP:8080首次访问会看到解锁页面。Jenkins 生成的管理员初始密码存放在 JENKINS_HOME 下的 secrets 文件中cat /root/.jenkins/secrets/initialAdminPassword把输出的字符串复制粘贴到页面输入框进入下一步。接着选择插件安装方式。初学建议选择“安装推荐的插件”Jenkins 会自动安装 Git、Pipeline、SSH 等常用插件。这一步需要几分钟时间取决于服务器和你所选插件源之间的网络速度。插件安装完成后创建第一个管理员用户设置好 Jenkins 的访问地址整个初始化流程就结束了。4.3 Jenkins 界面设置中文新版本 Jenkins 安装完成后默认界面是英文的。英文界面本身不影响使用但如果你更习惯中文操作可以通过插件解决。进入Manage Jenkins→Plugins→Available plugins在搜索框输入Localization: Chinese (Simplified)安装该插件。安装完成后进入Manage Jenkins→Appearance→Locale将语言设置为zh_CN保存后刷新页面即可。这里有一个小坑中文插件只是界面翻译不影响底层配置项。你配置 Job 时看到的英语参数名在日志和报错中仍然会以英文形式出现所以不要把中文界面当成避开英语的理由。5. 在 Jenkins 中安装配置 Git5.1 安装 GitJenkins 拉取代码时本质上是在服务器上执行 git 命令所以必须先在操作系统层面安装 Git。CentOS 7 自带 git 的安装源直接执行yum install -y git git --version正常输出版本号即可。如果项目使用的是 Git 私有仓库例如 Gitee、GitLab 或公司内网 Git 服务器还需要考虑认证问题。这一步经常被忽略导致后续 Jenkins 构建时拉不到代码。5.2 配置 Git 用户信息与免密Jenkins 拉取代码通常需要认证常见有两种方式。第一种是 HTTP 凭据方式。在 Jenkins 里保存仓库账号密码构建时以credentialsId引用。这种方式配置简单但每次仓库密码变更需要同步修改 Jenkins 凭据。第二种是 SSH 免密方式。在 Jenkins 所在服务器生成 SSH 密钥把公钥添加到 Git 平台。对经常和 GitLab、Gitee 打交道的小团队来说这种方案更省心。生成密钥ssh-keygen -t ed25519 -C jenkinsexample.com cat ~/.ssh/id_ed25519.pub把输出的公钥内容添加到 Git 平台的 SSH Keys 配置中。为保险起见还要配置用户信息git config --global user.name jenkins git config --global user.email jenkinsexample.com5.3 Jenkins 全局配置中添加 Git操作系统安装好 git 之后还需要在 Jenkins 中声明 Git 可执行文件的路径。进入Manage Jenkins→Tools找到Git installations填写 Path to Git executable 为/usr/bin/git保存。这一步如果不做Jenkins 的 Git 插件可能无法定位 git 命令即使系统里已经装了 Git构建时仍然会报错。6. 在 Jenkins 中安装配置 Maven6.1 Maven 在 Jenkins 中的定位Maven 在 Jenkins 流程里主要负责以下三件事根据 pom.xml 解析依赖坐标下载依赖到本地仓库执行编译、测试、打包生命周期。与 Git 不同Maven 不是由 Jenkins 自动探测的它不会因为你在服务器上执行了mvn -v就让 Jenkins 找到 Maven。Jenkins 的插件机制要求你在全局工具配置里手工指定 Maven 的安装目录再加上 Jenkins 自身的环境变量隔离机制很多初学者在这里耗掉大量时间。6.2 下载 Maven 并配置环境变量进入/opt/tools目录下载 Maven 3.9.x 二进制包。这里以 3.9.6 为例如果你已经在中国环境使用可以替换为官网最新版本cd /opt/tools wget https://archive.apache.org/dist/maven/maven-3/3.9.6/binaries/apache-maven-3.9.6-bin.tar.gz tar -zxvf apache-maven-3.9.6-bin.tar.gz mv apache-maven-3.9.6 /opt/tools/maven接着配置系统环境变量echo export MAVEN_HOME/opt/tools/maven /etc/profile echo export PATH$PATH:$MAVEN_HOME/bin /etc/profile source /etc/profile mvn -v执行mvn -v能看到 Maven 版本和 JDK 信息说明 Maven 安装成功。这里显示出的 Java 版本信息也是后面排查构建问题的关键线索。6.3 配置 settings.xml 与国内镜像仓库Maven 的全局配置文件位于${MAVEN_HOME}/conf/settings.xml。正式使用前建议修改两个配置项。第一是本地仓库位置。默认本地仓库在用户目录的.m2/repository下如果你希望 Jenkins 构建和本地开发共用一套依赖缓存或者想统一管理磁盘占用可以指定一个固定目录localRepository/opt/tools/maven-repo/localRepository第二是镜像仓库。不配置镜像时Maven 默认从中央仓库下载依赖网络较慢或依赖较多时体验很糟糕。以阿里云公共仓库为例在 settings.xml 的mirrors节点中添加mirror idaliyunmaven/id mirrorOfcentral/mirrorOf namealiyun public/name urlhttps://maven.aliyun.com/repository/public/url /mirror如果公司有私服 Nexus可以把mirrorOf改得更精确比如central,jcenter并把 URL 指向私服地址。配置多个镜像时Maven 会按mirrorOf的匹配规则选择生效的镜像不会同时使用两个。6.4 Jenkins 全局配置中添加 Maven完成系统层面的安装后进入 Jenkins 的Manage Jenkins→Tools找到Maven installations点击Add Maven填写 Name 为maven-3.9MAVEN_HOME 填/opt/tools/maven保存。这里填写的 Name 必须和后续 Pipeline 脚本中的tools名称保持一致。如果你在 Jenkins 里配的名字是maven-3.9而脚本里写的是maven-3.8构建时同样会报找不到工具。同理如果服务器上还有其他版本的 JDK也可以在同一个页面里配置多个 JDK 安装项让不同的 Job 使用不同的 JDK。7. 完整示例创建第一个 Pipeline 构建任务7.1 准备一个可构建的 Java 项目在创建 Jenkins 任务之前准备一个简单的 Maven 项目。项目结构大致如下java-demo/ ├── pom.xml └── src/ └── main/ └── java/ └── com/example/DemoApplication.javapom.xml 中至少包含项目坐标和 Maven 编译插件这里不展开完整内容。重点是项目的目录必须先提交到 Git 仓库因为 Jenkins 构建的第一步就是拉取这个仓库。7.2 编写 Pipeline 脚本在 Jenkins 首页点击New Item输入任务名称选择Pipeline。在 Pipeline 配置区域将 Definition 设为Pipeline script然后把下面的脚本粘贴进去。pipeline { agent any tools { maven maven-3.9 } stages { stage(拉取代码) { steps { git url: https://gitee.com/yourname/java-demo.git, branch: main, credentialsId: gitee-credentials } } stage(编译打包) { steps { sh mvn clean install -DskipTests } } stage(运行测试) { steps { sh mvn test } } stage(部署到服务器) { steps { sh scp target/java-demo-1.0.0.jar root192.168.1.10:/opt/app/ } } } post { success { echo 构建成功 } failure { echo 构建失败请查看控制台日志 } } }这里有几个关键点需要解释。tools里的名称maven-3.9必须与第 6.4 节在 Jenkins 全局工具配置里填写的 Name 一致。credentialsId是 Jenkins 凭据的标识需要提前在Manage Jenkins→Credentials中添加 Git 仓库的账号密码或 SSH 密钥并把 ID 写入脚本。scp部署到目标服务器时需要把 Jenkins 所在机器的 SSH 公钥加入目标服务器的授权列表否则这一步会卡在密码交互弹窗导致构建无法继续。如果你的项目用 Docker 部署可以将最后一步替换为docker build和docker push把镜像推送到镜像仓库后再由目标服务器拉取。7.3 构建并验证点击任务页面的Build NowJenkins 会立即触发一次构建。点击构建历史中的编号进入控制台输出页面你会看到完整的执行过程。如果配置正确日志应该依次显示Git 拉取成功、Maven 构建进度、测试执行结果、scp 传输完成。最终出现构建成功或Finished: SUCCESS字样说明整条链路已经打通。构建完成后进入 Jenkins 工作空间的 target 目录可以确认 jar 包是否生成。默认工作空间路径是/root/.jenkins/workspace/任务名。这一步验证非常必要能帮助你确认 Jenkins 和 Maven 是否真的完成了协作而不仅仅是 Jenkins 界面显示成功。7.4 通过 Blue Ocean 查看流水线视图Jenkins 默认的任务进度页是列表式的不够直观。安装 Blue Ocean 插件后Pipeline 任务会呈现为泳道式视图每个 Stage 的状态一目了然。在Manage Jenkins→Plugins中搜索安装Blue Ocean之后在 Jenkins 首页点击Open Blue Ocean即可查看。Blue Ocean 不是必需的组件但它能帮助你更快定位某个阶段失败的问题调试 Pipeline 时尤其好用。8. 常见问题与排查思路问题现象可能原因排查方式解决方案访问服务器 IP:8080 打不开防火墙未放行端口执行firewall-cmd --list-ports放行 8080 端口检查云安全组构建时提示mvn: command not foundJenkins 未加载系统环境变量在 Pipeline 中执行sh mvn -v验证在全局工具配置中添加 Maven 路径Git 拉取代码报Permission denied服务器未配置 Git 免密手工执行git ls-remote 仓库地址生成 SSH 密钥公钥添加到 Git 平台Maven 依赖下载极慢使用中央仓库而非镜像查看 settings.xml 中的 mirror 配置配置阿里云或公司私服镜像构建报unable to find valid certification path to requested targetMaven 下载源证书不被 JVM 信任查看私服 HTTPS 证书是否可信将私服证书导入 JVM cacerts或改用公网可信仓库本地构建成功但 Jenkins 构建失败本地与 Jenkins 的 JDK/Maven 版本不一致对比两边java -version和mvn -v在 Jenkins 全局工具中锁定与项目一致的版本中文注释或日志乱码系统默认字符集不是 UTF-8执行locale查看字符集设置LANGen_US.UTF-8或 Jenkins 启动参数加-Dfile.encodingUTF-8表格里的每一条都对应一个真实踩坑点。排查这类问题的通用思路是先看控制台日志中第一处出现的 ERROR 行顺着它往上找通常就能定位是环境问题、权限问题还是脚本问题。补充说明一下证书问题。如果你在公司私服下载依赖时遇到证书报错安全的做法是把私服的 HTTPS 证书导入到 Jenkins 所用 JDK 的cacerts证书库。不建议为了省事把整个 Maven 源切到 HTTP。9. 最佳实践与工程建议9.1 统一版本避免“本地能构建、Jenkins 失败”本地开发环境能构建CI 环境却失败是最常见的团队协作问题。根本原因大多是版本不一致本地 Maven 3.9 构建正常CI 里却装的是 Maven 3.6项目用 JDK 17 编译CI 却默认使用 JDK 8。建议在项目根目录的 Jenkinsfile 中显式声明 JDK 和 Maven 版本并在 Jenkins 全局工具配置里安装多个版本备用。对于新项目可以直接通过 Maven 的 Toolchains 机制锁定 JDK 版本从源头消除版本漂移。9.2 凭据管理要放到 Jenkins 凭据中心不要把 Git 仓库密码、服务器密码直接写在 Pipeline 脚本或 Jenkinsfile 里。Jenkins 提供了凭据中心可以把账号密码、SSH 密钥、Secret Text 统一管理脚本中用credentialsId引用。这样做的好处是敏感信息与环境配置分离即使 Pipeline 脚本被同事阅读也不会泄露密码。9.3 Pipeline 脚本要进代码仓库把 Jenkinsfile 作为独立文件提交到 Git 仓库并在 Jenkins 任务中选择Pipeline script from SCM。这样做的意义在于构建流程的每次变更都能走代码评审出错时可以快速回滚也不会出现“只有某个人会在 Jenkins 界面上配置”的单点问题。9.4 构建产物要规范化命名jar 包或 war 包的命名建议包含项目名和版本号可以使用 Maven 的finalName配置统一。这样做的好处是当构建产物需要回滚或归档时你能从产物名直接判断版本而不是靠猜测。如果团队已经使用 Nexus 或 Artifactory 这类制品仓库建议把构建产物推送上去由制品仓库负责版本管理和分发。Jenkins 只负责构建和触发发布职责会更清晰。9.5 通知与告警要尽早接入构建失败的反馈速度直接影响 CI 流程的使用质量。Jenkins 本身支持邮件通知配置 SMTP 后可以在任务中启用构建失败通知。如果团队使用飞书或钉钉也可以利用插件或 Webhook 把构建结果推送到群机器人。通知不需要在第一次搭建时就配置得很复杂但至少要保证构建失败时不是只有手动刷新 Jenkins 页面才能发现。9.6 定期清理构建记录与工作空间长时间运行后Jenkins 的构建记录、工作空间、Maven 本地仓库会占用大量磁盘。可以在全局配置中设置构建记录保留策略例如只保留最近 30 天对于工作空间可以在 Pipeline 结束后清理不再需要的临时文件或者对整个 Job 启用工作空间清理插件。磁盘满了会导致 Jenkins 构建直接失败这类问题往往到报警后才会被发现。写在最后把 Git、Maven、Jenkins 串起来只是自动化交付的第一步。真正让这套流程稳定的是后续对版本、凭据、产物和通知的持续管理。建议你按照本文的顺序先跑通一个最小可用的 Pipeline再逐步把部署方式的细节补充进去不要一开始就追求覆盖所有场景。后续值得继续深入的方向有两个一是把构建产物推送到 Nexus 私服并配置版本号自动递增二是用 Docker 或 Kubernetes 部署方案替代当前的 scp 部署方式让 Jenkins 专注于编排调度。先把基础链路跑稳再沿着这两个方向演进是成本最低、收益最明确的路。