Jenkins本身不自动部署，它只负责调度和执行；所谓“全链路自动化部署”，是指从代码提交开始，到构建、测试、打包、推送镜像、上线服务、通知反馈这一整套动作全部由Jenkins自动完成，中间无需人工干预。
Jenkins 本身不自动部署，它只负责调度和执行。所谓“全链路自动化部署”，是指从代码提交开始，到构建、测试、打包、推送镜像、上线服务、通知反馈这一整套动作全部由 Jenkins 自动完成，中间无需人工干预。实现的关键不是装个 Jenkins 就行，而是把每个环节串起来、配对、验证通。
核心逻辑很明确：Jenkins 是指挥中心，真正干活的是你写的脚本、调用的命令、集成的工具。
需要打通的五个关键链路节点
- 代码触发：Git 提交后自动拉起构建
- 环境就绪：Jenkins 能调用构建工具（Maven/Node.js）、能连 Docker、能 SSH 到目标服务器
- 流程编排：用 Pipeline 显式定义每一步做什么、失败怎么处理
- 部署落地：新包传上去、旧进程停掉、新服务启起来、端口不冲突
- 结果闭环：成功发企业微信/邮件，失败立刻告警并留日志
每个节点怎么配才可靠
代码触发必须稳定，别靠轮询
- GitLab 或 GitHub 配 Webhook，指向 Jenkins 的
/project/任务名或/generic-webhook-trigger/invoke（需装插件） - 不要用“轮询 SCM”，延迟高、耗资源，还容易漏提交
- Webhook 要带分支过滤（如
refs/heads/main），避免 dev 分支误触发生产部署
构建环境不能“凭感觉”
- JDK、Maven、Node.js、Docker CLI 全部在 Jenkins → 全局工具配置里指定路径，不要写死在脚本里
- Agent 节点上提前装好 sshpass、rsync、curl 等常用命令，否则 pipeline 里
sh 'scp...'直接报 command not found - 若用 Docker 构建，推荐
docker-in-docker（dind）方案，比挂载宿主机 socket 更隔离、更安全
Pipeline 脚本要防错、可读、易维护
stage('Deploy') {
steps {
script {
// 先检查远程服务是否存活
if (sh(script: "ssh -o ConnectTimeout=5 user@192.168.1.100 'systemctl is-active --quiet myapp'", returnStatus: true) == 0) {
sh "ssh user@192.168.1.100 'systemctl stop myapp'"
}
// 再传包、解压、赋权、启动
sh "scp -o StrictHostKeyChecking=no target/app.jar user@192.168.1.100:/opt/myapp/"
sh "ssh user@192.168.1.100 'chmod +x /opt/myapp/app.jar && systemctl start myapp'"
}
}
}- 每个
sh命令加returnStatus: true判断，配合if控制流程，避免一条失败后续还跑 -
$WORKSPACE、$BUILD_NUMBER这类内置变量优先用，别硬写/var/lib/jenkins/workspace/xxx - 敏感信息（密码、token）一律走 Credentials Binding，别明文写进脚本
部署动作必须原子、可回滚
- 不是“覆盖 jar 就完事”。得有 pid 文件或 systemctl 管理，确保旧进程真停了
- 生产建议用蓝绿或滚动更新：先起新实例，健康检查通过后再切流量，旧实例等下线
- 至少保留最近 3 个构建产物，归档到
archiveArtifacts 'target/*.jar'，回滚时直接选历史构建重部署
通知和日志不能省
- 构建失败时，用 Email Extension Plugin 或企业微信 Bot 发消息，带上控制台链接和失败行号
- 所有部署操作记录到远程服务器的
/var/log/myapp/deploy.log，方便追查“到底哪步卡住了” - Jenkins 自身日志开 debug 级别（
jenkins.model.Jenkins），排查插件问题时很有用
全链路不是堆功能，而是让每个环节都经得起反复触发、失败可定位、变更可追溯。配好了，一次提交，三分钟上线；配不好，天天救火查 Permission denied (publickey)。
