.net-core - 如何避免 EF Core 迁移和自定义迁移操作（自定义 SQL）的部署错误

Question

我在我的 .NET Core 项目中使用 EF Core 迁移，并使用 DevOps 管道进行部署。

在我的构建管道中，我使用命令行任务构建迁移 SQL 脚本来执行dotnet ef migrations script命令（使用--idempotent选项），然后使用 Azure SQL 数据库部署任务在发布管道中执行它。一切都相当标准，从简单的谷歌搜索（例如这里）判断，这是我首先了解该方法的方式。

这是我的问题：为了达到某些预期的结果，在我的一些迁移中，我使用自定义迁移操作 ( migrationBuilder.Sql("...")) 来执行一些手工制作的 SQL 作为迁移的一部分。

但是，随着项目的发展，我的数据库模式会随着时间的推移而变化，旧的此类迁移不可避免地包含不再适合模式的 SQL。有人会认为这不是问题，因为任何迁移都只适用于具有某些特定模式版本的数据库。然而，事实证明，该dotnet ef migrations script命令构建了一个带有一堆条件 SQL 块的 SQL 脚本，如下所示：

IF NOT EXISTS(SELECT * FROM [__EFMigrationsHistory] WHERE [MigrationId] = N'20190123160628_SomeMigrationId')
BEGIN
    /* Generated or custom SQL here */
END;

注意：每个迁移都包含在脚本中，IF NOT EXIST 子句确保只有尚未应用的迁移在数据库中执行。

但是，自定义迁移任务 SQL 语句按原样包含在脚本中，如果它们过时，它们将不再编译。然后数据库部署任务失败，整个部署也是如此。

有没有其他人遇到过并解决了这个问题，或者知道另一种部署没有这个问题的迁移的方法？在我看来，这严重影响了 MigrationBuilder.Sql() 命令的实用性，这是在迁移过程中任意“按摩”数据的唯一方法。

标签： .net-coreentity-framework-coreazure-pipelinesentity-framework-core-migrations