EF Core Code First 運行時遷移回滾策略與持續部署

Question

我有一個在啟動時使用 EF Core 運行時遷移的服務：

var migrator = dbContext.Database.GetService<IMigrator>();
await migrator.MigrateAsync("targetMigration", cancellationToken);

為了生成遷移，我首先更新 DbContext class，然后執行“do.net ef migrations add”以生成遷移代碼。

發生遷移后，部署的升級可能會自動回滾到以前的版本。 例如，如果健康檢查或測試失敗。 在這種情況下，我希望以前版本的應用程序能夠自動回滾遷移。 我知道 MigrateAsync 可以恢復遷移，但在我當前的工作流程中，遷移代碼不會出現在以前版本的代碼中，所以我不確定它是否能夠恢復遷移。

我可以想到這樣的工作流程：

1. 更改 DbContext 並運行“do.net ef add migration”以生成遷移代碼

2. 還原 DbContext 更改並部署應用程序，以便遷移代碼“n”存在，但 MigrateAsync 中的目標遷移和 DbContext 的版本為“n-1”

3. 重新應用 DbContext 更改，將 MigrateAsync 更改為目標遷移“n”，然后部署應用程序

但這看起來很尷尬，我不確定是否有必要，是否一定有效。

使用 EF Core 部署代碼優先運行時遷移的好策略是什么，這樣如果部署了以前的版本，遷移可以自動回滾？

Answer 1

據我所知，EF 沒有為你的情況准備任何東西，在產品中來回遷移真的很困難，而且，你必須考慮到許多遷移會造成數據丟失。

首先，當必須很好地測試更改時，您需要創建一個流程，當更改投入生產時，您應該 99% 確定產品中不會出現回滾。

正如您所說，您需要最新版本的代碼，否則，EF 將不知道“向下”應該做什么。

在我們當前的系統中，我們分析每個遷移，如果是新表或簡單的東西，我們只是從 CI 運行遷移。 如果它更復雜，或者我們需要更復雜的移動（修改數百萬行的表），我們只需手動完成，這樣我們就可以將數據發送到臨時表，填充空數據或使用我們剛剛生成的特殊函數腳本並使用它。

dotnet ef migrations script 20190725054716_Add_new_tables

這是一個非常難的問題，Java 和 JPA 共享相同的問題來生成歷史記錄。

這些遷移生成器非常適合開發，但很難用於生產環境，不斷變化的環境，特別是當您需要像您一樣來回 go 時，另一種選擇是使用其他工具來處理為這種情況准備得更好的遷移，例如liquibase

另一個想法可以在這里找到：

我最終創建了一個自定義工具，它可以智能地執行遷移並自動確定要使用哪個 model（上下文）程序集進行遷移。