设计完整的数据库迁移堆栈答案

【问题标题】：Designing a full database migration stack设计完整的数据库迁移堆栈
【发布时间】：2012-03-15 06:09:57
【问题描述】：

在开发过程中，我喜欢使用 Entity Framework 4.3 Migrations 之类的框架（尽管我需要它来处理 sql 脚本而不是 Migration 类）让所有开发人员数据库保持最新。有人进行更新以获取最新源，他们尝试运行应用程序并收到错误，他们需要将数据库更新到最新迁移（或让迁移自动发生）。迁移文件带有时间戳，因此开发人员不必担心将两个文件命名为相同或文件需要执行的顺序。

当我准备构建 WebDeploy 部署包时，我希望该包包含将生产数据库移动到最新数据库版本所需的脚本。所以不知何故，MSBuild 或 WebDeploy 需要决定必须打包哪些脚本。对于部署，我不希望应用程序尝试像 EF 提供的那样更新自身。我想要么将包交给 IT 部门，要么通过部署服务器进行自动部署。

我的一些问题是：

EF 4.3 能否使用 sql 脚本而不是 DBMigration 类来满足我的开发需求（我已经将它用于我的 ORM，所以如果可以的话会很好）？
MSBuild 或 WebDeploy 是否了解数据库迁移的概念（例如，它是否识别 EF.4.3 migrationHistory 表）或者我是否必须确保只提供它需要运行的脚本，这将带来我的产品db 到最新的迁移？手动决定应该打包哪些脚本不是我想做的事情，是否有理解迁移的 MS WebDeploy 扩展？
我的担忧和想法有效吗？我只是在研究这些东西，所以我真的不知道。

【问题讨论】：

标签： database-migration webdeploy build-server entity-framework-migrations entity-framework-4.3

【解决方案1】：

我认为您的担忧是有道理的。在开发过程中，任何使开发人员机器保持同步的事情都可以做到。部署时，需要更多控制。

在我的项目中，我们决定只使用基于代码的迁移，以确保所有数据库都以相同的顺序和相同的步骤进行迁移。自定义初始化策略禁用自动迁移和创建数据库，该策略仅检查数据库是否存在且有效。

我在Prevent EF Migrations from Creating or Changing the Database 中写了更多关于细节的文章。我还对merge conflicts 进行了一些研究，这最终会发生在多个开发人员身上。

【讨论】：

【解决方案2】：

您可以通过调用 Sql 方法在类中运行 SQL，或者使用带有 update-database 命令的 -script 参数从迁移中生成 SQL。
没有。他们正在考虑增加对 webdeploy 的支持，但显然在 rtm 之前决定反对它。然而，他们确实发布了一个命令行应用程序（显然还有 powershell 脚本），您可以从中调用它。

我在我的项目中所做的是在我的应用程序中创建一个启动模块并运行任何尚未自动部署的迁移 - Triggering EF migration at application startup by code。这并不完美，开发人员必须在获取最新版本之后才能运行应用程序，然后才能更改数据库，但它适用于获取最新版本和部署。

【讨论】：