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

Question

在开发过程中，我喜欢像实体框架4.3迁移这样的框架(尽管我需要它来使用sql脚本而不是迁移类)来保持所有开发人员数据库的更新。有人进行更新以获得最新的源代码，他们试图运行应用程序，并获得一个错误，需要将数据库更新为最新的迁移(或者迁移自动发生)。迁移文件是有时间戳的，因此devs不必担心将两个文件命名为相同或需要在其中执行的顺序。

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

我的一些问题是：

1. 对于我的开发需要，EF4.3是否可以使用sql脚本而不是DBMigration类(我已经将它用于ORM，所以如果可以的话会更好)？
2. MSBuild或WebDeploy是否理解数据库迁移的概念(例如，它是否承认EF )。4.3 migrationHistory表)，还是必须确保只给它运行的脚本，以便将prod用于最新的迁移？手动决定哪些脚本应该被打包并不是我想要做的事情，有一个MS WebDeploy扩展可以理解迁移吗？
3. 我的担心和想法有效吗？我只是在研究这些东西所以我真的不知道。

Answer 1

我认为你的担忧是正确的。在开发过程中，任何保持开发人员机器同步的事情都可以。在部署时，需要更多的控制。

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

我用防止EF移动创建或更改数据库写了更多关于细节的文章。我还研究了一些合并冲突，这将最终发生在多个开发人员身上。

Answer 2

1. 您可以通过调用SQL方法在类中运行Sql，也可以通过使用-script参数和update-database命令从迁移中生成SQL。
2. 不是的。他们考虑增加对webdeploy的支持，但显然在rtm之前决定不支持它。不过，他们确实发布了一个命令行应用程序(显然还有powershell脚本)，您可以从其中任何一个调用它。

我在项目中所做的是在我的应用程序中创建一个启动模块，并运行尚未自动部署的迁移- 在应用程序启动时通过代码触发EF迁移。这并不完美，开发人员必须在获得最新的应用程序之后才能更改db，但是它既适用于get最新版本，也适用于部署。