核心是代码提交自动触发jenkins拉取、编译、打包、部署全流程：需安装验证git、maven（兼容jdk11/17）、jenkins（rpm或docker），配置webhook或轮询触发，设置凭证与clean选项，编写含maven构建和shell部署的脚本，并确保权限、绝对路径及错误兜底。
在 Linux 环境下用 Jenkins + Git 实现自动构建发布，核心是让代码提交触发 Jenkins 拉取、编译、打包、部署全流程。整个过程不依赖人工点击，关键在于环境准备、服务联动和脚本可控。
基础组件安装与验证
确保以下工具已正确安装并可用：
-
Git：用于拉取远程仓库代码。执行
git --version验证；若需新版，建议源码编译安装（如 Git 2.30+），避免 CentOS 7 默认的 1.8 版本不支持某些钩子特性 -
Maven：Java 项目构建主力。解压后配置
MAVEN_HOME和PATH，运行mvn -v确认 JDK 11/17 兼容性及本地仓库路径无权限问题 -
Jenkins：推荐使用官方 RPM 包或 Docker 部署。RPM 方式注意修改
/etc/sysconfig/jenkins中的JENKINS_USER（建议设为root或专用用户）和端口；Docker 启动时务必挂载/var/jenkins_home并赋予宿主机对应目录读写权限
Git 仓库对接与触发配置
让 Jenkins 感知 Git 提交变化，有两种主流方式：
-
Webhook 方式（推荐）：在 Git 仓库（GitLab/GitHub/Gitee）设置 Webhook，URL 填 Jenkins 的
/project/任务名/notifyCommit（GitLab 则用/gitlab/builds或通过 GitLab 插件配置）；需生成并填写 Secret Token，Jenkins 端启用 GitLab API 插件并测试连通 -
轮询方式（备用）：Jenkins 任务中勾选 “Poll SCM”，填写类似
H/5 * * * *的 cron 表达式（每 5 分钟检查一次），适合内网或无法开放回调地址的环境，但实时性略差
无论哪种方式，源码管理里都要填对仓库 URL、选择对应凭证（用户名/密码 或 SSH Key），并勾选 “Clean before checkout” 避免残留文件干扰构建。
构建任务与部署脚本编写
自由风格项目中，构建步骤本质是一系列可执行命令：
-
Maven 构建：Goals 填
clean package -Dmaven.test.skip=true（跳过测试加快流程），指定settings.xml路径以使用私有镜像源 -
Shell 部署逻辑：在 “Execute shell” 步骤中写实际动作，例如：
export BUILD_ID=dontKillMe（防止 Jenkins 杀掉后台进程）cp target/*.jar /opt/app/systemctl restart myapp.service
或针对 Tomcat：rm -rf /opt/tomcat/webapps/ROOT*cp target/*.war /opt/tomcat/webapps/ROOT.war -
错误兜底：脚本开头加
set -e，任一命令失败即终止；结尾用exit 0显式返回成功，避免因后台进程未退出导致构建状态异常
权限与稳定性要点
很多失败源于权限或环境变量缺失：
- Jenkins 进程启动用户（如
jenkins用户）必须对 Maven 本地仓库、Tomcat webapps 目录、目标部署路径有读写权限；建议统一用root启动或提前chown -R jenkins:jenkins /path - 所有命令尽量用绝对路径（如
/usr/local/maven/bin/mvn），避免 Jenkins 使用的 shell 环境与手动执行不一致 - 首次构建失败时，优先看 Jenkins 控制台输出——重点排查 git clone 权限、maven 下载依赖超时、jar 包找不到、systemctl 权限拒绝等高频问题
