如何在Azure DevOps流水线中回滚迁移包？是否符合最佳实践？

一、流水线中实现回滚的具体操作 #

针对Entity Framework迁移，回滚的核心是将数据库恢复到上一个稳定的迁移版本，在Azure DevOps流水线中可以这样配置：

• 在应用迁移的步骤后添加条件执行的回滚步骤，设置触发条件为迁移步骤失败（condition: failed()）
• 执行回滚命令：
  • .NET CLI方式：dotnet ef database update <上一个迁移的名称/ID>
  • Package Manager Console方式：Update-Database <上一个迁移的名称/ID>

注意：需确保流水线执行环境已安装EF工具，可通过dotnet tool install --global dotnet-ef预先部署。

二、回滚是否属于最佳实践？ #

回滚是故障恢复的必要补救手段，但不能单独算作最佳实践。完整的迁移最佳实践应覆盖全流程：

• 迁移前强制备份：执行迁移前自动备份数据库（如Azure SQL启用自动备份，或流水线中添加备份脚本步骤）
• 预环境验证：所有迁移脚本必须先在 staging 环境测试，确认无兼容性问题
• 编写幂等脚本：保证迁移脚本多次执行不会产生异常（比如用IF NOT EXISTS判断数据库对象是否存在）
• 拆分大迁移：将包含大量变更的迁移拆分为多个小步骤，降低回滚风险
• 实时监控告警：迁移过程中输出详细日志，失败时立即触发告警，便于快速响应

回滚只是问题发生后的止损手段，前置的预防措施才是减少故障的核心。

三、手动查询__EFMigrationsHistory表的方式是否可行？ #

可行，但不推荐作为常规操作：

• EF迁移工具本身就依赖__EFMigrationsHistory表跟踪数据库迁移状态，dotnet ef database update命令会自动读取该表并完成回滚，无需手动查询
• 手动操作易出错：比如误选迁移版本、并发场景下表数据变动、拼写错误导致回滚到错误状态
• 若需确认当前迁移状态，可在流水线中添加SQL查询步骤（如SELECT TOP 1 MigrationId FROM __EFMigrationsHistory ORDER BY CreatedOn DESC），但回滚仍建议使用EF官方命令执行

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