jenkins无原生rescue机制，回滚依赖post段失败分支+版本锚定+备份快照；每次构建生成唯一产物并存档，deploy失败后post→failure触发回滚至上一健康版本，并做健康检查与通知。
Jenkins 本身没有原生的 rescue 关键字或“异常中断瞬间强制触发回滚”的实时拦截机制。所谓“在异常中断瞬间”自动执行回滚，实际依赖的是 阶段失败后的显式控制流设计，而非底层信号捕获。真正可行、稳定、被生产环境广泛验证的方式，是通过 Declarative Pipeline 的 post 段 + 阶段化版本锚定 + 外部备份快照 构建出具备“失败即回滚”语义的自动化流程。
下面直接说清楚怎么做：
回滚必须基于可复现的构建版本
每次成功构建都应生成唯一、带元数据的产物（如 app-${BUILD_ID}-${GIT_COMMIT}.jar），并同步存入制品库（Nexus/Artifactory）或远程备份目录。关键不是“中断瞬间”，而是失败发生后，能立刻定位到上一个已知健康的版本。
-
BUILD_ID是 Jenkins 内置变量，稳定可用 - 建议在
build阶段末尾用sh 'cp target/app.jar /backup/app-${BUILD_ID}.jar'显式归档 - 不要依赖
lastSuccessfulBuild—— 它可能被并发构建污染
在 deploy 阶段失败时自动执行回滚逻辑
Declarative Pipeline 的 post 支持按结果分支执行，但注意：post { failure { ... } } 只在当前整个 Pipeline 运行结束且状态为 failure 时触发，不是“中断瞬间”，但效果等价于“失败后立即响应”。
你可以在 deploy 阶段内部嵌套容错逻辑，也可以统一收口到 post。推荐后者，更清晰、易审计。
pipeline {
agent any
stages {
stage('Build') {
steps {
sh 'mvn clean package -DskipTests'
sh 'cp target/app.jar /backup/app-${BUILD_ID}.jar'
}
}
stage('Deploy') {
steps {
script {
// 模拟部署：先停服务，再替换 jar，再启服务
sh 'systemctl stop myapp'
sh 'cp /backup/app-${BUILD_ID}.jar /opt/myapp/app.jar'
sh 'systemctl start myapp'
// 部署后健康检查，失败则抛异常，让 stage 标记为 failed
timeout(time: 60, unit: 'SECONDS') {
waitUntil {
sh(script: 'curl -sf http://localhost:8080/actuator/health | grep UP', returnStatus: true) == 0
}
}
}
}
}
}
post {
failure {
echo "Deploy failed → triggering rollback to last known good version"
script {
// 获取上一次成功构建的 BUILD_ID（需提前记录，例如写入文件或查 API）
def lastGood = sh(script: 'cat /backup/last_good_build_id || echo "123"', returnStdout: true).trim()
echo "Rolling back to build ${lastGood}"
sh 'systemctl stop myapp'
sh 'cp /backup/app-${lastGood}.jar /opt/myapp/app.jar'
sh 'systemctl start myapp'
// 更新当前 last_good 标记（可选，用于下次回滚参考）
sh 'echo ${lastGood} > /backup/current_rollback_target'
}
}
success {
// 当前构建成功，标记为新的“last good”
sh 'echo ${BUILD_ID} > /backup/last_good_build_id'
}
}
}
关键保障点：让回滚本身也具备原子性与可观测性
- 所有
sh命令建议加returnStatus: true并手动判断，避免因单条命令失败导致回滚流程静默中断 - 回滚操作本身也要做健康检查（例如重启后调
curl验证端口响应），失败需明确报错，不能“假装成功” - 把
/backup/last_good_build_id存在共享存储或数据库中，避免单机故障丢失上下文 - 在
post → failure中发送企业微信/钉钉通知，附带BUILD_URL和回滚版本号，便于追溯
不复杂但容易忽略。
