部署管道如何回滚代码

部署管道（CI/CD Pipeline）的代码回滚核心目标是：快速恢复稳定版本，最小化故障影响。下面按常见场景和最佳实践系统说明。

一、回滚的核心原则

1. 回滚 ≠ 重新部署旧代码
   • 更推荐：重新部署上一个已知可用的版本
2. 可回滚的前提
   • 有版本化制品（镜像、Jar、War、包）
   • 部署是可重复、可追踪的
3. 优先保证可用，再排查原因

二、常见回滚方式（按部署类型）

✅ 1. 基于版本号的回滚（最推荐）

适用： Kubernetes、云原生、容器化部署

Kubernetes 示例

kubectl rollout undo deployment/my-app

回滚到指定版本：

kubectl rollout history deployment/my-app
kubectl rollout undo deployment/my-app --to-revision=2

✅ 优点：

• 秒级回滚
• 自动保留历史版本

✅ 2. 重新部署上一个 Git 版本（CI/CD 常见）

流程：

1. 找到上一个稳定 commit
2. 重新触发 CI/CD Pipeline
3. 部署该 commit 对应的制品

示例：

git checkout <last-stable-commit>
git tag rollback-20260121
git push origin rollback-20260121

然后在 CI/CD 中：

• 选择该 tag 重新部署

✅ 适合：

• Jenkins
• GitLab CI
• GitHub Actions

✅ 3. 蓝绿部署回滚（最安全）

原理：

• 蓝环境：当前版本
• 绿环境：新版本
• 出问题 → 切回蓝环境

回滚方式：

• 切换负载均衡 / Ingress / Service
• 不做重新部署

✅ 优点：

• 回滚几乎无感知
• 常用于生产环境

✅ 4. 金丝雀 / 灰度回滚

回滚方式：

• 停止新版本流量
• 将流量 100% 切回旧版本

示例（Istio）：

route:
- destination:
    host: my-app
    subset: v1
  weight: 100

✅ 5. 数据库相关回滚（⚠️ 高风险）

代码可以回滚，数据库不一定能

正确做法：

• 使用 可逆变更
• 使用迁移工具（Flyway / Liquibase）

✅ 可回滚示例：

ALTER TABLE user ADD COLUMN age INT;
-- 回滚
ALTER TABLE user DROP COLUMN age;

❌ 不可回滚示例：

DROP TABLE order;

✅ 最佳实践：

• 先不改表结构
• 新字段允许 NULL
• 新旧代码兼容

三、CI/CD 中的回滚策略

Jenkins

• 使用 Pipeline 参数
• 选择版本号回滚

parameters {
  choice(name: 'ROLLBACK_VERSION', choices: ['v1.2', 'v1.1', 'v1.0'])
}

GitLab CI

rollback:
  only:
    - tags
  script:
    - deploy.sh $CI_COMMIT_TAG

GitHub Actions

• 手动触发 workflow
• 选择 tag / commit 部署

四、回滚标准流程（推荐）

1. 确认故障
   • 日志 / 监控 / 报警
2. 决策：回滚 or 修复
   • 修复 > 30 分钟 → 回滚
3. 执行回滚
   • 优先流量切换
   • 其次重新部署
4. 验证
   • 健康检查
   • 核心接口
5. 复盘
   • 为什么回滚
   • 如何避免

五、回滚 Checklist（生产必看）

✅ 是否有上一个可用版本
✅ 是否有回滚脚本 / 自动化
✅ 数据库是否兼容
✅ 配置 / 环境变量是否一致
✅ 回滚是否可验证

六、一句话总结

好的回滚不是“能回”，而是“敢回、快回、安全回”。

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

• 你用的是 K8s / 虚拟机 / 云厂商
• CI/CD 工具（Jenkins / GitLab / GitHub Actions）
• 是否有数据库变更

我可以给你一套完全贴合你系统的回滚方案。