最有效的方法在很大程度上取决于部署管道的工作方式——生产前有多少环境、发布周期、部署的哪些部分是自动化的。没有通用的“最佳实践”——每种处理迁移的方式都有自己的权衡需要注意。根据您的需求和期望选择升级程序。
在为中型项目（大约 70 个表）设置 EF Core 迁移时，我尝试了几种可能的方法。我对过程的观察以及最终的结果：
- 您希望在更改模型和部署到生产之间的某个位置获得迁移 SQL，如果只是查看它，以防有任何可能导致回滚问题的重大更改。我们决定使用 dbcontext 直接在项目中进行迁移，并
dotnet ef migrations script --idempotent为每个可能部署到任何环境的构建生成一个迁移脚本（使用 ）——在我们的例子中，每次推送到主干或发布分支都有一个 CI 步骤。
- 将迁移 SQL 置于版本控制中并将 SQL 视为数据库结构的真实来源，当您想要保留某些列以用于备份或向后兼容时，可以手动修改脚本。另一种选择是将您的数据模型视为数据库模式的参考，并将迁移 SQL 视为不保留的中间步骤，这使得整个过程更容易自动化，但需要您直接在数据模型中处理特殊情况。
- 在生成迁移脚本时使用
--idempotent标志为您提供了一个脚本，您可以将其重新应用于数据库模式，而不管它处于什么模式版本，让它只执行尚未执行的步骤。这意味着您可以将相同的迁移脚本重新应用于已迁移的数据库，而不会破坏架构。如果您有不同版本的应用程序在不同的环境（开发、登台和生产环境）中并行运行，它可以节省手动跟踪您需要应用的迁移脚本版本和顺序的问题。
- 当您有迁移 SQL 时，您可以将本机用于您的数据库工具，以便将它们应用到目标环境 - 例如
sqlcmd用于 SQL Server、psql用于 postgres。这还有一个好处是让具有更高权限（模式修改）的单独用户处理迁移，而您的应用程序在有限的权限下工作，通常无法触及模式。
- 应用数据库迁移是应用程序部署的一部分，而不是应用程序启动 - 如果你有某种部署自动化，它可能是对目标数据库执行迁移的最佳位置，再次 - 数据库本地客户端是一个很好的替代方案
DbUp，选择你喜欢的任何一个. 将迁移与应用程序启动分开还使您能够针对不匹配但仍兼容的数据库模式运行应用程序 - 例如，当您进行部署部署时，这很方便。
- 模式升级的大多数问题来自破坏版本之间的模式兼容性 - 避免这种情况需要在处理数据模型时注意向后/向前兼容性并将破坏性更改拆分为单独的版本，以保持至少单步向后/向前兼容性 - 无论您需要这取决于你的项目，这是你应该决定的。我们针对当前数据库模式运行先前版本的完整集成测试套件，并针对先前数据库模式运行当前版本，以确保在两个后续版本之间没有引入重大更改 - 任何移动多个版本的部署都将一一推出迁移，假设该迁移脚本或应用程序启动可以包括从旧模型到新模型的数据转换。
总而言之：生成迁移 SQL 并在版本部署上使用本机工具或 DbUp 可以让您在一定程度上手动控制迁移过程，并且可以通过自动化部署过程来实现易用性。出于开发目的，您也可以在应用程序启动时添加自动迁移，最好仅在环境设置为时才应用Development- 只要团队中的每个人都有自己的开发数据库（本地 SQL，共享服务器上的个人，filedb，如果你使用 SQL）无需担心冲突。