部署脚本测试方法实战指南

部署 脚本为何要测试

上线新功能时，最怕的就是脚本一跑，服务挂了。以前团队里有个同事写了个部署脚本，顺手把数据库配置路径写错了，结果生产环境连不上数据库，半夜三更打电话叫人回公司救火。这种事情多了，大家就意识到：脚本不测，等于埋雷。

部署脚本不是写完就能直接扔到服务器上跑的。它涉及文件复制、权限设置、服务重启、环境变量加载等多个环节，任何一个出问题都会导致应用无法正常启动。所以，得像对待代码一样，给它配一套可靠的测试方法。

最简单的测试方式就是在本地搭一个接近生产的环境。比如用 Docker 起一个和线上一致的服务容器，再执行一遍部署脚本。这样能快速发现路径错误、命令缺失这类低级问题。

例如，你的脚本里有这一步：

cp -r ./dist /var/www/html

但如果目标目录没有写权限，或者 /var/www/html 根本不存在，脚本就会卡住。在本地先跑一遍，配合 set -e 让脚本遇到错误立即退出，能第一时间暴露问题。

别指望一次跑通所有步骤。把部署拆成“构建 → 传输 → 替换 → 启动 → 健康检查”几个阶段，每一步都加日志输出和状态判断。

比如在脚本中加入：

echo "[INFO] 正在停止旧服务..."
systemctl stop myapp || { echo "[ERROR] 停止失败"; exit 1; }

然后在测试时人工或用自动化工具检查这些输出是否符合预期。就像做饭时尝一口咸淡，每个步骤都要能“尝得出来”。

脚本跑完了不代表万事大吉。得确认服务真的起来了。可以写个简单的健康检查脚本，比如请求 /health 接口，看返回是不是 200。

curl -f http://localhost:8080/health
if [ $? -ne 0 ]; then
    echo "[ERROR] 服务未正常启动"
    exit 1
fi

这个小检查可以在部署后自动运行，也能手动触发。曾经有个项目，脚本把新版本拷过去了，但忘了重启进程，结果用户访问的还是旧代码。加了健康检查之后，这种乌龙再没发生过。

把部署脚本集成进 CI/CD 流程，每次提交代码都先在测试环境走一遍。Jenkins、GitLab CI 或 GitHub Actions 都支持这种模式。

比如 GitLab CI 的 .gitlab-ci.yml 里加个 stage：

deploy_staging:
  stage: deploy
  script:
    - bash deploy.sh --env staging
  only:
    - main

这样每次合并到主分支，就会自动在测试环境部署一次。发现问题也不影响线上，相当于提前排雷。

测试不仅要验证成功路径，还得考虑失败怎么办。脚本里最好内置回滚逻辑，比如备份旧版本目录。

cp -r /var/www/html /var/www/html.bak.$(date +%Y%m%d-%H%M%S)

万一新版本出问题，能快速切回去。测试时也得演练回滚流程，不能只测“往上推”，不测“往回拉”。

实际工作中，见过太多团队只关注“怎么部署上去”，没人管“怎么撤下来”。等真出事了才发现回滚脚本从来没测过，权限不对、路径丢失，越搞越乱。