我最早对部署这件事的印象是一条命令敲三遍本地打包、上传、重启。等到功能频繁改动的时候这三步的代价就被放大了——每天重复几十次每次都要等编译、等传输、等启动中间还要忍受手动找进程号、kill、再启动的紧张感。后来我花了一个下午用Shell把“Maven构建—产物上传—远程重启”串成一条命令从此这个项目的发布就变成了一句话。这篇文章不聊复杂的CI/CD平台只说开发人员实用的一层Shell自动化编译、打包、部署Java项目怎么设计脚本、怎么避免翻车以及我从这套方案里踩过的真实问题。如果你也是开发人员不是专职运维暂时不需要为一个小项目引入完整的流水线系统那这套思路可以直接拿过去改着用。就算以后上了正式发布平台这里面的脚本逻辑也完全能作为平台里的某个阶段保留下来不会白写。1. 为什么要给Java项目做Shell自动化而不是先上CI/CD1.1 Shell方案真正适合的场景先给这套方案划个边界。我推荐用Shell自动化不是因为它能取代所有工具而是因为它非常贴合“个人开发、小团队、临时环境、快速验证”这四类场景。比如手头维护一个内部工具系统就两台服务器测试环境和生产环境各一台改动频率一天好几次。这时候你要硬上一套完整的发布平台光维护平台本身的时间可能比手动部署还多。反过来如果你面对的是几十个节点的微服务集群、多环境编排、灰度发布那当然应该上更规范的发布系统。Shell脚本在这个量级下会变得非常难管环境差异、并发发布、权限隔离都是问题。所以我的判断标准很简单项目复杂度低、机器数量少、发布动作固定就用Shell工程量上来了再考虑平台化。两者不是对立关系而是分阶段的选择。另外很多新手容易犯的错是一上来就写“万能脚本”想在一个脚本里处理所有项目的所有情况。我的建议是先只服务一个项目把编译、打包、部署三条主流程跑通等稳定后再考虑抽象成模板。1.2 和CI/CD平台的分工其实不是二选一有人会问既然以后还是要上CI/CD现在花时间写Shell不是浪费吗实际不是。我在不少团队里见到过一种组合方式发布平台负责触发、权限审批、通知真正干活的还是一段Shell脚本或由Shell编排的执行命令。平台提供“什么时候发布、谁允许发布、发布结果给谁看”Shell负责“怎么编译、怎么传包、怎么启动”。所以你现在写的这些逻辑本质上就是未来流水线里的执行步骤。从学习路径上说先把Shell调教明白你对构建过程的理解会非常扎实。理解了mvn package产物在哪、进程怎么启动、日志怎么输出再去配置可视化流水线完全是小菜一碟。反过来说如果一上来就在界面上点按钮出了问题排查起来反而更抓瞎。1.3 写脚本前先守住三条原则我写了第一版脚本后陆续改了很多轮最后发现三条原则是必须守住的第一是幂等。同一个脚本同一套参数连续跑两次不应该把环境搞坏。比如上传前先备份启动前先停掉旧进程健康检查失败不追加新包。这样就算你手滑点多次执行也不会出现端口冲突或包名错乱。第二是可观测。脚本不是“跑完就算成功”的盲盒。每一步该打印什么信息、日志写到哪个文件、失败时保留哪一段现场都要提前设计好。很多时候排障靠的就是启动那一刻的日志尾巴没有日志运维和开发都会非常被动。第三是可回滚。部署前备份当前运行的版本一旦新包启动失败有明确的一条命令或脚本参数能退回上一个可用版本。别把“回滚”想成高级功能它就是cp加kill加nohup的组合写起来并不难但关键时刻能救命。2. 脚本目录与前置依赖开始写代码前先想清楚三件事2.1 脚本目录怎么规划才不会越用越乱我见过不少开发者的服务器上脚本文件乱放在/root、/home/user、/tmp下面时间一长完全分不清谁是谁。我的建议是单独开一个deploy目录把脚本、配置、产物、日志分开。下面是我常用的结构可以直接参考deploy/ ├── scripts/ │ ├── build.sh │ ├── deploy.sh │ ├── rollback.sh │ └── common.sh ├── conf/ │ ├── env-dev.sh │ ├── env-test.sh │ ├── env-prod.sh │ └── app.conf ├── releases/ │ ├── dev/ │ └── test/ └── logs/脚本放scripts环境差异放conf构建产物放releases日志统一在logs。这样做的原因是把变化的东西和不变的东西分开。build.sh和deploy.sh写完之后很少改动真正天天变的是服务器地址、端口、JVM参数、应用目录这类环境信息。它们被抽到配置文件里之后新加一套环境就只需要新增一个conf/env-xxx.sh脚本主体一行不用动。2.2 构建机器和远程服务器分别需要装什么先列一个依赖清单缺什么补什么本地构建机需要安装JDK、Maven、Git、OpenSSH客户端还有rsync如果只想用 scp可以不要。远程服务器需要装JDK如果你用jps或pgrep查进程建议把JDK的bin目录加进PATH。有一个细节容易被忽略本地JDK版本和远端JDK版本最好保持一致。否则本地用Java 17编译远端还是Java 8运行时经常出现UnsupportedClassVersionError这种问题。脚本层面能做的事很有限不如在环境准备阶段就统一版本。Maven仓库也很关键。如果是内网开发settings.xml里要配好私服镜像地址否则第一次编译时会卡在下载依赖上。我一般在脚本开头加一小段环境自检command -v java /dev/null 21 || { echo java not found; exit 1; } command -v mvn /dev/null 21 || { echo mvn not found; exit 1; }这段的作用是快速暴露问题。早上换上新的开发机第一回跑脚本就清楚缺了什么不用等到编译失败才回头查。2.3 环境差异必须集中管理刚写自动化的时候我最常犯的毛病是把服务器IP和端口直接硬编码在脚本里。一开始还能忍等到测试环境从一台机器换到另一台、或者新加了一个预发环境就得打开脚本东改一行西改一行非常容易漏。现在我的做法是把每个环境都变成一个配置文件。比如conf/env-test.sh长这样REMOTE_HOST192.0.2.10 REMOTE_USERdeployer REMOTE_DIR/opt/app/order-center APP_PORT8080 JVM_OPTS-Xms512m -Xmx1024m -Duser.timezoneAsia/Shanghai KEEP_RELEASES5脚本里通过source conf/env-${ENV}.sh加载对应配置。这样做的好处有两个一是换环境、换机器只需改文件隔离了“代码”和“配置”二是脚本里不会出现任何真实环境敏感信息哪怕仓库被误拉取别人也看不到有效的服务器账号密码因为密码根本不写在脚本里而是靠SSH密钥完成认证。3. 编译打包环节一条Maven命令背后的细节3.1 Maven命令组合不是随便敲的绝大部分Java后端项目的构建命令可以归结为这样一行mvn clean package \ -DskipTests \ -Dmaven.test.skiptrue \ -Prelease这里每个参数都有它存在的理由。clean会清理target目录避免上次构建的残留文件干扰打包结果package负责把项目打成可执行的jar或war-DskipTests表示跳过测试执行但会编译测试代码-Dmaven.test.skiptrue更狠连测试代码都不编译。很多人的脚本里两个都写上我一般会留一个就行选哪个取决于你们项目测试代码是否经常编译报错。如果你确定这轮发布不需要测试代码参与直接-Dmaven.test.skiptrue构建速度会快一些。-Prelease是激活Maven profile用来处理环境相关的构建配置。比如release profile里可能把日志级别换成WARN或者引入生产环境专用的配置中心。具体要哪个profile最好由脚本参数来控制而不是每次手动改pom.xml。3.2 构建时如何处理版本号Java项目发布时最常见的问题就是jar包名字一直叫xxx-1.0-SNAPSHOT.jar每次都覆盖上一个文件根本没法回滚。我建议不要在脚本里频繁改pom版本而是给每一次构建生成一个带时间戳的部署版本号。先看一段最简单的时间戳处理STAMP$(date %Y%m%d-%H%M%S) JAR_NAMEorder-center-${STAMP}.jar JAR_FILEtarget/${JAR_NAME}然后打包之后把target/order-center-*.jar重命名成带时间戳的名字。这样每个发布包天然有唯一标识看到文件名就知道是什么时间构建的。部署的时候远程目录里会同时存在几个历史包想回滚时只要指定一个时间戳就行。如果你确实需要在Maven层面覆盖版本号可以用mvn versions:set -DnewVersion1.2.3 mvn clean package但这会改动pom.xml相当于对你的源码产生了副作用。我更推荐构建完不碰源码只在产物归档阶段做重命名把“源码版本”和“部署版本”解耦。日志流水、监控面板上报的版本号可以用同一个时间戳排查问题的时候反而更容易对应上构建记录。3.3 构建产物的归档策略target里的东西只是中间状态真正需要长期保留的是每次构建出来的jar包。我在脚本里会安排两步第一步把构建成功的jar复制到releases/目录mkdir -p releases cp $JAR_FILE releases/${JAR_NAME}第二步做历史清理。保留最近N份其余删掉。这里的N由环境配置里的KEEP_RELEASES控制ls -1t releases/order-center-*.jar | tail -n $((KEEP_RELEASES 1)) | xargs -r rm -f清理动作不要省略。时间戳命名的产物只增不减两个月后磁盘被历史包塞满的戏码一定会重演。建议顺带把编译日志也落盘mvn clean package -Dmaven.test.skiptrue 21 | tee logs/build.logtee的好处是既能在终端实时看到输出又能把完整日志存下来。后面部署失败时logs/build.log就是第一手证据。4. 部署环节从本地到远端最难的不是传文件4.1 免密通道别在服务器密码上偷懒本地构建机和远程服务器之间要传文件、执行命令第一步建议配置SSH免密登录而不是用sshpass这类脚本里硬塞密码的方案。密码会过期会出现在命令行历史和日志里一旦服务器密码被修改脚本立刻失效。SSH key只要配一次长期稳定很多。生成密钥并分发到目标机器ssh-keygen -t ed25519 -C deploylocal ssh-copy-id deployer192.0.2.10测试连接ssh deployer192.0.2.10 echo ok如果端口不是22在~/.ssh/config里配好别名比如Host test-server HostName 192.0.2.10 User deployer Port 2222之后脚本里就能直接用ssh test-server远程地址这种长字符串不用到处出现。传文件的选择上jar包在100MB以内用scp足够超过这个量级或者希望断点续传用rsync -avz更稳。我把两种命令都给出来scp $JAR_FILE test-server:/opt/app/order-center/releases/rsync -avz $JAR_FILE test-server:/opt/app/order-center/releases/4.2 远程进程控制优雅停止比 kill -9 更重要部署最紧张的一步就是停旧进程。直接kill -9当然省事但可能会让Spring Boot来不及做清理工作偶尔还会出现端口未释放、临时文件残留的问题。我的脚本里优先用普通kill发TERM信号让应用自行退出。远程执行时比较麻烦的是在Shell脚本里嵌套远程命令。下面是一段我早期用过的停止逻辑remote_stop() { ssh test-server PID\$(pgrep -f ${APP_NAME}.jar | head -1) if [ -n \\$PID\ ]; then kill \$PID echo \stopped pid \$PID\ else echo \no running process\ fi }这里有一个非常容易踩的坑\$和\的转义。因为在双引号字符串里$(pgrep ...)和$PID都会被本地Shell先解释一遍必须加上反斜杠才能让远端Shell收到原始含义。这也是为什么我后来更推荐“本地只调远程脚本”的做法在远端服务器放一个start.sh或stop.sh本地只执行ssh test-server bash /opt/app/order-center/stop.sh转义复杂度瞬间降下来。远端start.sh的核心其实很简单#!/usr/bin/env bash APP_NAMEorder-center JAR_FILE${APP_NAME}-$(ls -1t .../releases/ | head -1) nohup java ${JVM_OPTS} -jar ${JAR_FILE} app.log 21 echo started, pid $!4.3 JVM参数和启动参数统一管理JVM参数在普通部署过程中很容易被忽略但它又是线上问题定位的金钥匙。我建议至少加上堆内存限制、时区、OOM转储这几项JVM_OPTS-Xms512m -Xmx1024m -Duser.timezoneAsia/Shanghai -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/opt/app/order-center/logsHeapDumpOnOutOfMemoryError尤其重要。内存溢出后自动生成dump文件分析工具能很快定位是哪个对象占用了空间。如果没有这一项OOM之后你只能看着中断日志干着急。启动时还要注意必须用nohup加把进程放到后台不然SSH会话一断开应用跟着就没了。现在Java进程基本都是java -jar xxx.jar的形式所以pgrep -f能匹配到启动PID直接用$!也能拿到。我习惯每启动一次就把PID写到一个app.pid文件里后续恢复或检查都方便。4.4 健康检查启动成功不等于服务可用很多人部署完看一下进程还在就觉得成功了。实际上Spring Boot启动需要时间外部依赖没就绪时端口可能一直在LISTEN但请求全部报错。我在脚本里加了一层健康检查循环remote_healthcheck() { for i in $(seq 1 30); do if curl -fsS http://127.0.0.1:${APP_PORT}/actuator/health /dev/null 21; then echo healthcheck ok after ${i} attempts return 0 fi sleep 2 done echo healthcheck failed return 1 }如果你的应用没有暴露健康检查端点至少用curl -I看HTTP状态码或者检查日志里是否出现了Started关键字。这一步的意义是不给失败留下任何蒙混过关的机会。健康检查不通过脚本就要立即进入回滚流程把上一个jar重新部署上去而不是让未就绪的新服务在外悬着。5. 一份可以直接改着用的deploy.sh框架5.1 脚本骨架参数解析、环境加载、函数分流下面是把我实际项目里用到的脚本精简后的核心框架可以直接照着改成自己的项目#!/usr/bin/env bash set -euo pipefail SCRIPT_DIR$(cd $(dirname ${BASH_SOURCE[0]}) pwd) ENVtest BRANCHmaster while getopts e:b: opt; do case $opt in e) ENV$OPTARG ;; b) BRANCH$OPTARG ;; *) echo Usage: $0 -e [test|prod] -b [branch] ; exit 1 ;; esac done source ${SCRIPT_DIR}/../conf/env-${ENV}.sh source ${SCRIPT_DIR}/common.shset -euo pipefail这三个选项我强烈建议加上。-e让脚本在命令出错时直接退出-u防止使用未定义变量pipefail避免管道命令中间失败被末尾命令掩盖。这三行能省掉大量“脚本看着成功、实际早挂了”的迷惑场面。然后是构建函数和部署函数do_build() { git checkout ${BRANCH} git pull --rebase mvn clean package -Dmaven.test.skiptrue -Prelease 21 | tee logs/build.log STAMP$(date %Y%m%d-%H%M%S) JAR_NAMEorder-center-${STAMP}.jar cp target/order-center-*.jar releases/${JAR_NAME} } do_deploy() { rsync -avz releases/${JAR_NAME} test-server:/opt/app/order-center/releases/ ssh test-server bash /opt/app/order-center/stop.sh ssh test-server JAR_NAME${JAR_NAME} bash /opt/app/order-center/start.sh ssh test-server bash /opt/app/order-center/healthcheck.sh }主函数只负责按顺序调用并且把每一阶段的耗时打出来main() { echo build time do_build echo deploy time do_deploy echo deploy success } main5.2 容错与告警的几个细节第一无论构建还是部署每一步失败都要能留下痕迹。我在common.sh里加了一个错误陷阱trap echo error at line $LINENO; tail -50 logs/build.log ERR这样脚本一旦任意一步失败终端会立刻显示出错的是哪一行并自动带出构建日志尾部。第二发布前旧包备份。远程启动新jar之前我先确保上一个jar还在/releases目录里。为了不覆盖我会把旧包先复制成order-center-rollback.jar回滚时直接指定它。第三不建议在脚本里直接写rm -rf清理远程目录。变量为空时rm -rf ${REMOTE_DIR}/可能变成rm -rf /这种事故代价太大。我通常用find ... -delete精确匹配文件名模式避免全目录误删。5.3 日常使用效果一条命令发布一套服务实际跑起来的时候效果就是终端里滚动几行日志大概四十秒到一分钟内看到 deploy success 。以前手动部署至少要开三个终端一个打包一个传文件一个看日志现在只需要一行./scripts/deploy.sh -e test -b master如果想更顺手可以在~/.bashrc里加一个别名alias dep~/deploy/scripts/deploy.sh之后每天发测试环境就是dep -e test。发布过程中如果哪个环节慢了别去盯着滚动日志直接用tail -f logs/deploy.log打开另一个窗口看细节即可。6. 这套Shell部署方案真正难住我的五个问题6.1 远程执行命令时被本地变量“抢走”了值我最早踩得最多的坑就是SSH远程命令里的变量展开问题。比如我想查远端有没有Java进程直接写ssh test-server echo $(hostname)结果打印的是本地主机名因为$(hostname)在本地已经执行完了。同理$JAR_NAME、$PID这些变量如果不转义或不用单引号都会出问题。我的经验是能本地算好的值就在本地算好需要远端扩展的变量一定要用\$转义。实在复杂的时候别硬凑一行远程命令改用“本地传脚本参数远端执行脚本”的组合比如ssh test-server JAR_NAME${JAR_NAME} bash /opt/app/order-center/start.sh这样远端脚本内部可以自由使用$JAR_NAME本地不用关心转义。6.2 进程查不到时set -e反而让脚本崩了pgrep -f app.jar找不到进程时返回非0而set -e会让脚本直接退出。本来“没有旧进程”是正常情况但脚本却把它当错误处理了。我后来给这类判断加上了保护PID$(pgrep -f ${APP_NAME}.jar || true) if [ -n $PID ]; then kill $PID fi|| true的意思是把非0返回“吞掉”让脚本继续走。如果你不想看到set -e带来的各种意外可以先不用它但对新手来说直接把set -e去掉又会回到“命令失败但脚本继续跑”的混乱状态。所以正确做法就是学会处理那些本身可能失败的判断类命令。6.3 时间戳命名的jar让磁盘持续增长时间戳方案带来回滚方便副作用就是目录里的jar包越来越多。我曾经两个月没清理一台测试服务器上堆了上百个发布包快照磁盘被占满。后来我在每个环境的配置文件里加了KEEP_RELEASES5每天执行一次find加ls -t的组合清理这个问题才算根治。不要等到磁盘报警再来处理。让脚本在每次部署成功后顺手清理掉过期包成本几乎为零但能让异常情况离你远一些。6.4 旧进程没停干净新进程却“启动成功”还有一次比较折磨的经历是旧进程卡在停止流程中占着8080端口新jar包又起来了但端口起不来日志里全是BindException。偏偏我的健康检查只看进程是否存在于是脚本报“部署成功”实际服务完全访问不了。后来我调整了启动前检查逻辑先确认端口已经释放再启动新进程。判断端口是否释放的方式很简单ssh test-server ss -tlnp | grep :${APP_PORT} /dev/null exit 1 || echo port free确保端口空出来后再执行启动。启动后再用健康检查做二次确认。多花这两三秒能避免一次看起来成功实则翻车的发布。6.5 断线之后没人知道服务处于什么状态最后遇到的问题是网络中断。远程上传到一半本地SSH连接断了脚本停在半路新jar没起来、旧jar被停掉服务瘫在那里而大家还以为在正常发布。这个问题没有完美的答案但我做了两件事一是远程启动包和本地日志全落盘断线后可以从日志恢复现场二是启动脚本把PID写入app.pid重启机器后至少能知道上次是谁在跑。现在部署前我也会习惯性地看一眼待发布jar是否已经完整传到远端用ls -l对比一下大小存在疑问就重新传一遍。很多时候脚本的稳健不是靠某个高级特性而是靠这些看起来“笨但可靠”的检查。最后说一点我自己的使用体会。这套Shell自动化方案我从只服务一个测试环境一直用到同时支持开发、测试、演示环境核心脚本几乎没有大改主要变的就是配置文件和环境数量。回想起来最大的收获不是省了多少时间而是让我把“发布”这件事从“感觉上差不多好了”变成了“有明确步骤、有日志、有回滚路径”的可信过程。如果你还在手动执行编译、scp、kill、nohup这一套不妨也花一个下午把流程沉淀成脚本体验一下一条命令部署Java项目带来的改变。