构建、测试、部署、回滚串联
成熟的流水线不是只有"部署成功"，而是把失败路径也设计进去——知道怎么回退，才敢往前走。
完整发布链
graph TD
A[代码推送] --> B[自动测试]
B --> C{测试通过?}
C -->|否| D[通知失败 停止]
C -->|是| E[构建制品]
E --> F[部署到目标环境]
F --> G[健康检查]
G --> H{检查通过?}
H -->|是| I[发布完成]
H -->|否| J[自动回滚]
每一环的价值
| 环节 | 目标 | 失败时处理 |
|---|---|---|
| 自动测试 | 拦截明显回归 | 通知开发者，禁止部署 |
| 构建制品 | 产出稳定可复现版本 | 记录失败日志，标记 build 不可用 |
| 部署 | 把版本推到目标环境 | 保留旧版本，不直接覆盖 |
| 健康检查 | 确认真实可用（不只是进程存在） | 触发自动回滚到上一个已知可用版本 |
最小 GitHub Actions 流水线（带回滚逻辑）
# .github/workflows/deploy.yml
name: Deploy
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run tests
run: npm ci && npm test
- name: Deploy to server
run: |
ssh deploy@${{ secrets.SERVER_IP }} << 'EOF'
cd /opt/myapp
git pull origin main
npm ci && npm run build
sudo systemctl restart myapp
sleep 5
curl -f http://127.0.0.1:3000/health || {
# 健康检查失败 → 回滚到上一个版本
git checkout HEAD~1
npm ci && npm run build
sudo systemctl restart myapp
echo "ROLLBACK triggered" && exit 1
}
EOF
常见误区
- "部署成功"等于"服务可用"：
systemctl restart myapp返回 0 只代表进程启动，不代表 HTTP 接口能正常响应，必须加健康检查 - 流水线没有通知机制：部署失败时如果没有发 Slack/邮件，可能很久后才发现生产环境异常
- 每次都强制用最新代码，没有制品版本：用 git hash 或 tag 标记每次部署的制品版本，出问题可以精确回滚到任意历史版本
本节执行清单
- [ ] 在流水线里加入自动测试步骤
- [ ] 部署后加健康检查（HTTP 200），失败触发回滚
- [ ] 给每次部署打上 git commit hash 标识
- [ ] 触发一次故意失败的测试，确认流水线能正确阻止部署
下一章：容器化与 Docker 运维入门——把交付环境进一步标准化。