通过一次 Jenkins 部署 jar 包,我终于理解了 Jenkins 在 CI/CD 里的真正作用 摘要以前我对 Jenkins 的理解一直比较零散知道它可以拉代码、打包、跑脚本、做自动部署但总觉得这些能力是分散的。这次我第一次用 Jenkins 把 jar 包部署到 CentOS 虚拟机并启动后才真正理解 Jenkins 在 CI/CD 中的定位。无论是我这次“手动上传 jar 包到 Jenkins再发布到虚拟机”还是公司里之前使用的 DevOps 流程“Jenkins 串 Git、构建、镜像、容器部署”本质上都是同一类事情Jenkins 负责流程编排、节点调度、制品传递和部署执行。区别只是制品形态从 jar 变成了镜像运行环境从虚拟机进程变成了容器。正文一、为什么这次实操让我对 Jenkins 的理解变了以前我知道 Jenkins 很重要但这种理解更多停留在“概念上知道”。比如我知道它可以拉代码执行脚本自动构建自动部署但这些点在我脑子里一直是分散的没有形成一个完整的闭环。直到这次亲手跑通 Jenkins 部署 jar 包到虚拟机我才真正把这些概念连接起来Jenkins 最核心的能力其实是流程编排。二、CI 和 CD 到底分别在解决什么问题CI/CD 这个词经常连在一起讲但我这次实操之后对它们的理解更具体了。CI持续集成CI 关注的是“代码如何稳定地产出可交付制品”。核心动作通常包括拉取代码编译测试打包生成构建产物CD持续交付/持续部署CD 关注的是“如何把构建好的产物稳定放到目标环境中运行”。核心动作通常包括选择部署目标下发制品启动服务校验结果完成交付我这次虽然没有让 Jenkins 从 Git 自动拉代码构建但已经完整体验到了 CD 的核心部分。三、Jenkins 在 CI/CD 中的核心作用是什么这次做完之后我会把 Jenkins 定义成交付流程的编排器和执行调度中心。它真正做的事情包括接收触发划分阶段调度节点传递制品执行命令输出结果留存日志所以 Jenkins 的核心价值并不是“它能执行一段脚本”而是它能把很多离散动作串成一条标准化流水线。四、从 jar 部署看 Jenkins 的工作方式我这次的部署流程虽然没有容器也没有镜像仓库但仍然非常典型。Java进程虚拟机AgentJenkins主节点Jenkins开发者Java进程虚拟机AgentJenkins主节点Jenkins开发者触发部署任务读取手动上传的jarstash制品调度部署阶段unstash制品覆盖目标目录jar停止旧进程启动新版本启动状态返回返回部署结果输出日志与结果从这里我第一次真正看懂了 Jenkins 的节点机制Jenkins 主节点不一定负责所有事情。不同阶段可以在不同节点执行。节点之间通过流水线传递制品。部署阶段真正的执行位置其实是在目标服务器本地。五、为什么说我这次做的事情本质上也是 CD很多人一说到 CI/CD就默认想到 Git、镜像、容器、Kubernetes。但这次我的场景其实很传统jar 包直接发到虚拟机。尽管如此它依然是一个标准的 CD 流程因为它具备了几个关键特征制品固定流程标准化交付动作自动完成部署结果可追踪过程可以重复执行所以我这次最大的理解升级之一就是CD 的本质不是有没有容器而是有没有一条自动、稳定、可重复的交付链路。六、jar 部署和 Docker 部署到底哪里相同这也是这次让我特别有感触的一点。我们公司以前的 DevOps 更常见的是Git 提交代码Jenkins 拉代码构建打镜像推镜像仓库发布到容器环境而我这次做的是手动上传 jar 包Jenkins 读取 jar 包Jenkins 调度目标虚拟机节点覆盖旧 jar启动 Java 进程表面看完全不同但如果抽象一下其实流程是一样的。七、jar 模式和容器模式的共同时序运行环境制品JenkinsGit/制品来源开发者运行环境制品JenkinsGit/制品来源开发者提交代码或准备制品触发流水线编排构建/部署阶段生成或读取制品下发制品并执行部署启动服务返回运行结果输出构建/部署结果在这条抽象链路里如果制品是 jar运行环境就是虚拟机上的 Java 进程如果制品是镜像运行环境就是容器平台所以在 Jenkins 的视角里变化的只是制品形态和运行载体不变的是交付逻辑。八、我这次最重要的认知升级1. Pipeline 是 Jenkins 的核心如果没有 PipelineJenkins 更像一个“点按钮执行任务”的平台。有了 PipelineJenkins 才真正成为一个流程编排系统。2. Agent 节点让 Jenkins 具备跨机器调度能力这次把目标虚拟机挂成 Jenkins Agent 节点之后我第一次真正理解了 Jenkins 不是只能在自己所在机器执行命令而是可以把任务调度到别的执行节点本地完成。3. Jenkins 解决的是流程自动化不是应用配置问题这次后面真正导致失败的并不是 Jenkins 本身而是Java 版本不匹配Apollo 地址不对环境参数缺失日志权限问题这让我意识到Jenkins 能帮你把流程自动化但不能替你解决应用自身配置和环境依赖。4. DevOps 不是某个工具而是一种交付方式以前我容易把 DevOps 理解成一个“大平台”或者“一套系统”。这次实践之后更能理解它其实是一条端到端的交付协同链路。而 Jenkins恰恰是这条链路里最关键的编排工具之一。九、回头再看公司里的 DevOps 流程现在再回头看公司之前那套 Git Jenkins Docker 的流程我就不再觉得它特别抽象了。因为底层逻辑其实已经很清楚Jenkins 接收代码变更或制品输入Jenkins 组织流水线阶段Jenkins 调度执行节点Jenkins 推动制品进入目标环境Jenkins 输出交付结果我这次做的 jar 部署和公司里的容器化发布本质上并没有变化。变化的只是输入来源不同制品形式不同运行环境不同但“交付流程”这件事本身是一致的。十、总结通过第一次用 Jenkins 部署 jar 包到虚拟机我终于把 Jenkins 在 CI/CD 里的作用理解完整了。现在如果让我用一句话概括 Jenkins我会这样说Jenkins 是连接代码、制品、执行节点和运行环境的流程编排中心。而这次最大的收获不是某一条命令会不会写而是我终于明白了Jenkins 为什么要有 PipelineJenkins 为什么要有 Agent 节点Jenkins 为什么能同时出现在 jar 部署和 Docker 部署中Jenkins 为什么是 CI/CD 落地里非常关键的一环