如何在发布失败时自动回滚到上一版本
解读
国内前端项目普遍采用“本地构建→上传产物→触发服务器脚本→切换软链或容器镜像”的发布模型。Grunt 本身只负责本地构建阶段，真正的“上线”动作往往由 Jenkins、GitLab CI、自建脚本或云厂商 CLI 完成。因此“发布失败”指的是产物上传后健康检查未通过，而“回滚”则是把线上软链/容器重新指向上一次可用版本。面试时，面试官想确认你是否理解Grunt 在整条链路中的边界，以及你能否设计一套低成本、可落地、符合国内运维习惯的自动回滚方案，而不是让 Grunt 去“越权”做服务器运维。
知识点
- Grunt 生命周期钩子：grunt.registerTask('deploy', ['build', 'upload', 'health', 'switch'])，可在任意一步通过this.async()返回 false 中断任务流。
- 国内常用“蓝绿 / 灰度 / 目录版本号”策略：每次构建产出带时间戳的目录，如 dist/202506031530，通过软链 webroot → dist/202506031530 实现秒级切换。
- 健康检查：curl 本地 127.0.0.1:8080/health，5 秒内返回 200 即成功；失败则回滚软链。
- 回滚信息持久化：把上一次软链目标写入 .prev symlink 或 redis，确保即使 Grunt 进程退出也能找回版本。
- 通知机制：接入企业微信 / 飞书群机器人，回滚后第一时间@责任人，符合国内“事故必须同步到群”的合规要求。
- 幂等性：回滚脚本必须可重复执行，避免二次回滚把系统带到更老版本。
答案
我采用“构建—上传—校验—切换—守护”五步法，让 Grunt 驱动整条流程并在校验失败时自动回滚：
-
版本号生成
在 Gruntfile 里用grunt.config.set('ver', Date.now())，确保每次构建目录唯一。 -
构建与上传
注册任务grunt.registerTask('build', ['clean', 'webpack', 'compress'])，随后调用 rsync 插件把 dist/{ver}`。 -
健康检查
自定义任务grunt.registerTask('health', function () { var done = this.async(); require('child_process').exec(ssh webserver "ln -sfn /data/release/${ver} /data/webroot_next && curl -m 5 -o /dev/null -s -w %{http_code} http://127.0.0.1:8080/health"`,
(err, stdout) => {
if (stdout.trim() === '200') {
grunt.log.ok('健康检查通过');
done();
} else {
grunt.fail.warn('健康检查失败，即将回滚');
done(false);
}
});
});` -
自动回滚
在 health 任务失败分支里，触发grunt.registerTask('rollback', function () { var done = this.async(); require('child_process').exec(ssh webserver "ln -sfn (readlink /data/webroot_prev) /data/webroot && echo '已回滚到 (readlink /data/webroot_prev)'", (err) => { if (!err) { grunt.log.error('回滚完成，已恢复上一版本'); done(); } }); });
通过grunt.registerTask('deploy', ['build', 'upload', 'health', 'switch']); grunt.task.run('deploy'); grunt.task.run('rollback');的链式失败捕获，确保 health 失败立即执行 rollback。 -
通知与记录
回滚后调用企业微信机器人接口，把版本号、回滚时间、责任人推送到运维群，同时在服务器写日志/var/log/deploy.log，方便后续审计。
该方案不修改服务器历史版本，仅切换软链，回滚耗时 <1 秒；且 Grunt 只负责驱动脚本，不直接操作线上流量，符合国内“最小权限”安全规范。
拓展思考
- 如果项目使用 Docker，可把上述逻辑改为“镜像 tag + kubectl rollout undo”：Grunt 构建完把镜像推到阿里云 ACR，CI 调用 kubectl set image 后等待 rollout status，失败则执行 kubectl rollout undo deployment/app。
- 对于金融级场景，可引入“二阶段提交”：先发布到 10% 的灰度节点，监控 5 分钟无异常再全量；Grunt 侧通过插件轮询 Prometheus 告警指标，一旦错误率 >1% 立即触发回滚脚本。
- 回滚脚本本身也要做单元测试：在测试环境模拟健康检查失败，验证软链是否正确恢复、通知是否送达，避免“回滚代码有 bug”导致二次故障。