部署管道回滚怎样操作

部署管道（CI/CD Pipeline）的**回滚（Rollback）**操作，核心目标是：在发现新版本有问题（故障、性能下降、逻辑错误等）时，快速、可控地恢复到上一个稳定版本，最小化业务影响。

下面按常见场景 + 实操方式系统说明。

一、回滚的总体原则

1. 可回滚前提

   • 有“上一个稳定版本”（镜像 / 包 / 配置）
   • 数据库变更可兼容或可逆
   • 回滚动作可自动化、可重复

2. 回滚 ≠ 删库重来

   • 优先“换版本”，不是“重建系统”

二、按部署方式分类的回滚操作

1️⃣ Kubernetes 部署回滚（最常见）

使用 Deployment

# 查看历史版本
kubectl rollout history deployment/my-app

# 回滚到上一个版本
kubectl rollout undo deployment/my-app

# 回滚到指定版本
kubectl rollout undo deployment/my-app --to-revision=3

✅ 优点：

• 原生支持
• 秒级切换
• 无停机（滚动回滚）

2️⃣ 蓝绿部署（Blue-Green）回滚

原理：新版本部署在 Green，流量在 Blue

回滚方式：

• 切换流量回 Blue

LB / Ingress:
Blue  ← 流量
Green（新版本，隔离）

✅ 回滚 = 切流量
❌ 不删 Green，便于排查

3️⃣ 金丝雀（Canary）回滚

回滚方式：

• 将 Canary 流量比例调回 0%
• 保留旧版本稳定实例

示例（Istio）：

route:
  - destination: v1
    weight: 100
  - destination: v2
    weight: 0

✅ 最安全
✅ 可逐步恢复

4️⃣ 虚拟机 / 物理机部署回滚

方式一：版本目录切换

ln -sfn /apps/app-v1.2 /apps/app-current
systemctl restart app

方式二：Ansible / Shell 回滚

- name: rollback app
  command: /deploy/rollback.sh v1.2

5️⃣ 容器镜像回滚（CI/CD）

在 Pipeline 中：

rollback:
  script:
    - docker pull myapp:1.2.0
    - kubectl set image deploy/my-app app=myapp:1.2.0

三、数据库回滚（最容易被忽略）

❗ 数据库回滚原则

• 应用可旧，数据库不可乱

常见策略

1. 向后兼容迁移
   • 只加字段，不删字段
2. 双写 / 影子表
3. 回滚脚本

ALTER TABLE orders DROP COLUMN new_field;

四、CI/CD 管道中的回滚设计

推荐 Pipeline 结构

build → deploy → smoke test → promote / rollback

自动回滚条件

• 健康检查失败
• 错误率 > 阈值
• 关键接口 5xx 增加

示例（GitLab CI）

rollback:
  when: on_failure
  script:
    - kubectl rollout undo deployment/my-app

五、回滚检查清单（生产必看）

✅ 当前版本号
✅ 上一个稳定版本号
✅ 配置是否变更
✅ 数据库是否兼容
✅ 监控 / 告警是否恢复
✅ 用户影响范围

六、最佳实践总结

• ✅ 回滚是一等公民，不是补救措施
• ✅ 每次发布都假设“可能要回滚”
• ✅ 回滚必须一键可执行
• ✅ 回滚后必须复盘（Postmortem）

如果你愿意，可以告诉我：

• 用的是 K8s / Jenkins / GitLab / ArgoCD / 云厂商
• 是 前端 / 后端 / 微服务 / 单体

我可以直接给你对应平台的回滚 YAML / 脚本模板。