如何在Azure DevOps CI/CD流水线中实现回滚操作？

一、手动触发回滚（基础易用） #

• 直接利用Azure DevOps发布管线原生功能：在发布界面找到目标环境的历史发布记录，选中已成功的旧版本，点击「回滚」并选择要恢复的环境，即可触发回滚操作。
• 提前配置对应回滚步骤：在部署任务后添加回滚任务组（比如删除新部署的应用文件、恢复旧配置、重启服务），确保回滚能精准撤销部署变更。例如针对.NET应用，可添加PowerShell任务删除新部署的wwwroot文件，从备份目录恢复旧版本文件。

二、自动化失败回滚（减少人工干预） #

• 启用阶段自动回滚：在发布管线的阶段设置中，勾选「如果此阶段失败，回滚到之前成功的部署」，指定回滚的目标版本规则（比如最近一次成功版本）。
• 自定义失败触发脚本：添加条件任务，当部署任务状态为「失败」时执行回滚逻辑。比如针对Azure App Service，用az webapp deployment slot swap命令切回旧部署槽；针对数据库，执行RESTORE DATABASE SQL命令恢复备份。

三、基于环境快照/版本镜像的回滚 #

• 部署前自动备份：在流水线部署步骤前添加资源备份任务：
  • 针对Azure VM：执行az vm snapshot create命令创建系统盘快照；
  • 针对Azure SQL：添加「Azure SQL数据库备份」任务，将备份文件存储到Blob存储；
  • 针对容器镜像：每次构建时标记旧版本镜像（如v1.0.0），回滚时直接拉取旧镜像重新部署。
• 回滚时恢复快照/镜像：触发回滚时，执行快照恢复命令或重新部署旧版本镜像，快速还原到部署前状态。

四、蓝绿/金丝雀部署模式下的回滚 #

• 蓝绿部署：维护两个一致的生产环境（蓝环境=当前运行版本，绿环境=待部署版本），验证通过后切换流量到绿环境。回滚只需将流量切回蓝环境，无需修改应用本身。可通过Azure DevOps部署组或App Service部署槽实现流量切换。
• 金丝雀部署：逐步将流量分配到新版本，若发现异常，立即停止流量分发并切回全量旧版本。可利用Azure App Service流量分拆功能，或借助Service Mesh调整流量比例，回滚时将流量100%切回旧版本。

五、Azure原生资源回滚能力 #

• App Service部署槽回滚：每次部署到staging槽，验证后交换到production槽。回滚时再次执行槽交换操作，即可快速恢复到交换前版本。
• ARM模板部署回滚：使用Azure CLI的az deployment group rollback命令，回滚到指定的历史成功部署版本。需确保部署时启用了部署历史记录，且资源支持回滚操作。

最佳实践 #

• 回滚步骤需与部署步骤一一对应，确保能完全撤销所有变更；
• 回滚后执行自动化测试，验证环境恢复正常；
• 记录回滚日志（触发原因、执行时间、恢复版本），便于后续排查。

内容的提问来源于stack exchange，提问作者Aswinkumar