如果不应该将 MigrateAsync() 用于生产环境，如何应用 EF Core 迁移？

Question

我创建了一个新的 .Net 5 项目并想使用 EF Core。我使用自动生成了多个 migration.cs 文件

dotnet ef migrations add MyMigration

并希望应用它们（用于开发和生产）。我知道这个MigrateAsync方法，所以我阅读了如何在启动时调用这个方法

https://andrewlock.net/running-async-tasks-on-app-startup-in-asp-net-core-part-1/

但在我读到的任何地方，这种方法都不应该用于生产，因为这些迁移不会在单个事务中执行（没有错误回滚）。

不幸的是，无论环境如何，都没有太多关于如何做到这一点的资源，我找到了这篇文章

https://www.thereformedprogrammer.net/handling-entity-framework-core-database-migrations-in-production-part-2

一种选择可能是调用迁移的控制台应用程序

https://www.thereformedprogrammer.net/handling-entity-framework-core-database-migrations-in-production-part-2/#1b-calling-context-database-migrate-via-a-console-app-or -管理员命令

但我无法理解这种方法的区别，因为它没有解决事务问题？

在开发/生产期间应用迁移的最佳实践是什么？

• 在自动生成迁移之后，我非常喜欢简单性，dotnet ef database update这项工作不需要我使用其他工具吗？

• 创建一个控制台应用程序，从迁移生成 .sql 文件，安装 DbUp 并将其用于迁移部分？

Answer 1

什么最有效在很大程度上取决于部署管道的工作方式——生产前有多少环境、发布周期、部署的哪些部分是自动化的。没有通用的“最佳实践”——每种处理迁移的方式都有自己的一套需要注意的权衡。根据您的需求和期望选择升级程序。

在为中型项目（大约 70 个表）设置 EF Core 迁移时，我尝试了几种可能的方法。我对这个过程的观察以及最后的结果：

1. 您希望在更改模型和部署到生产之间的某处获得迁移 SQL，如果只是为了查看它，以防有任何可能导致回滚问题的破坏性更改。我们决定直接在带有 dbcontext 的项目中进行迁移，并dotnet ef migrations script --idempotent为每个可能部署到任何环境的构建生成一个迁移脚本（使用）——在我们的例子中，每次推送到主干或发布分支的 CI 步骤。
2. 将迁移 SQL 置于版本控制中并将 SQL 视为有关数据库结构的真实来源，可以在您想要保留某些列以进行备份或向后兼容时手动修改脚本。另一种选择是将您的数据模型视为数据库模式的参考，并将迁移 SQL 视为不保留的中间步骤，这使得整个过程的自动化更容易，但需要您直接在数据模型中处理特殊情况。
3. --idempotent在生成迁移脚本时使用标志为您提供了一个脚本，您可以重新应用到数据库模式，而不管它的模式版本是什么，让它只执行尚未执行的步骤。这意味着您可以在不破坏架构的情况下将相同的迁移脚本重新应用于已迁移的数据库。如果您在不同的环境（开发、暂存和生产环境）中并行运行不同版本的应用程序，则可以避免手动跟踪您需要应用的迁移脚本版本和顺序。
4. 当你有迁移 SQL 时，你可以使用 native for your database 工具，以便将它们应用于目标环境 - 例如sqlcmd对于 SQL Server，psql对于 postgres。这也有一个好处，即让具有更高权限（架构修改）的单独用户处理迁移，而您的应用程序以有限的权限工作，通常无法触及架构。
5. 应用数据库迁移是应用程序部署的一部分，而不是应用程序启动 - 如果您有某种部署自动化，它可能是针对目标数据库执行迁移的最佳位置，同样 - 数据库本机客户端是一个很好的替代方案DbUp，选择您喜欢的任何一个. 将迁移与应用程序启动分开还使您能够针对不匹配但仍兼容的数据库模式运行应用程序 - 这在例如您进行推出部署时会派上用场。
6. 架构升级的大多数问题来自破坏版本之间的架构兼容性 - 避免这需要在处理数据模型时意识到向后/向前兼容性并将破坏性更改拆分为单独的版本，以保持至少一步的向后/向前兼容性 - 无论您是否需要这取决于你的项目，这是你应该决定的。我们针对当前数据库架构针对以前的版本运行完整的集成测试套件，针对以前的数据库架构针对当前版本运行完整的集成测试套件，以确保在两个后续版本之间不会引入破坏性更改 - 任何移动多个版本的部署都将逐步推出迁移，并假设迁移脚本或应用程序启动可以包括从旧模型到新模型的数据转换。

总结一下：生成迁移 SQL 并在版本部署上使用本机工具或 DbUp 使您可以在一定程度上手动控制迁移过程，并且可以通过自动化部署过程来实现易用性。出于开发目的，您也可以在应用程序启动时添加自动迁移，最好仅在环境设置Development为时应用- 只要团队中的每个人都有自己的开发数据库（本地 SQL，共享服务器上的个人，如果您使用 SQL) 无需担心冲突。