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

Question

在开发过程中，我喜欢实体框架4.3迁移等框架的想法（虽然我需要它使用sql脚本而不是迁移类），使所有开发人员数据库保持最新。有人进行更新以获取最新的源，他们尝试运行应用程序并获得将数据库更新为最新迁移所需的错误（或者自动迁移）。迁移文件带有时间戳，因此开发人员不必担心命名两个文件相同或者需要执行文件的顺序。

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

我的一些问题是：

1. EF 4.3可以使用sql脚本而不是DBMigration类来满足我的开发需求（我已经将它用于我的ORM所以如果它可以的话会很好吗？）

2. MSBuild或WebDeploy是否理解数据库迁移的概念（例如它是否识别EF.4.3 migrationHistory表）或者我是否必须确保只提供运行所需的脚本才能实现我的生产db到最新的迁移？手动决定应该包含哪些脚本不是我想要做的事情，那么是否有一个了解迁移的MS WebDeploy扩展？

3. 我的顾虑和想法是否有效？我只是在研究这些东西，所以我真的不知道。

Answer 1

我认为您的担忧是有效的。在开发期间，保持开发人员机器同步的任何事情都可以。部署时，需要更多控制。

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

我在Prevent EF Migrations from Creating or Changing the Database中写了更多关于细节的内容。我也看了一下merge conflicts，这最终将发生在多个开发人员身上。

Answer 2

1. 您可以通过调用Sql方法在类中运行SQL，或者通过使用-script参数和update-database命令从迁移生成SQL。

2. 没有。他们正在考虑增加对webdeploy的支持，但显然在rtm之前决定反对它。然而，他们确实发布了一个命令行应用程序（显然是powershell脚本），你可以从中调用它们。

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