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

Question

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

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

我的一些问题是：

1. 能EF 4.3使用SQL脚本，而不是DBMigration班我的发展需要的工作（我已经使用它为我的ORM所以它如果能够很好）？

2. MSBuild或WebDeploy是否理解数据库迁移的概念（例如它是否识别EF 4.3迁移历史表），还是必须确保仅为其提供运行所需的脚本，以便将我的prod db到最新的迁移？手动确定应该包含哪些脚本不是我想要做的，因此是否存在理解迁移的MS WebDeploy扩展？

3. 我的担忧和想法是否有效？我只是在研究这个东西，所以我不知道。

Answer 1

我认为你的顾虑是有效的。在开发过程中，任何使开发者机器保持同步的东西都可以。部署时需要更多的控制。

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

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

Answer 2

1. 可以通过调用SQL方法运行中的类SQL，或通过使用与更新的数据库命令的参数-script生成从迁移SQL。

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

我在我的项目做的是建立在我的应用程序的启动模块和运行没有被自动部署任何迁移 - Triggering EF migration at application startup by code。这并不完美，开发人员必须在更改db之前获取最新版本才能运行应用程序，但它适用于最新和部署。