从Application_Start迁移FluentMigrator

Question

我目前正在更改我们的数据库部署策略以使用FluentMigration，并且已经阅读了如何运行它。有些人建议可以从Application_Start运行，我喜欢这个想法，但其他人说不，但没有说明理由，所以我的问题是：

1. 在应用程序启动时运行数据库迁移是不是一个坏主意，如果是这样，为什么？
2. 我们计划将我们的网站迁移到部署到azure云服务，如果我们不从application_start运行迁移，我们应该如何/何时运行它，考虑到我们希望尽可能简化部署。 / LI>
3. 在哪里运行它们如何确保它只运行一次，因为我们将拥有一个网站和多个工作者角色（尽管我们可以确保只从网站调用迁移代码，但将来我们可能会增加到2个或更多实例，这是否意味着它可以运行多次？）

我非常感谢有关其他人如何在部署期间处理数据库迁移的任何见解，特别是从部署到Azure云服务的角度来看。

编辑：

查看下面的评论我可以看到在application_start期间运行的潜在问题，也许问题是我正在尝试用错误的工具解决问题，如果FluentMigrator不是要走的路，它可能不会在我们的情况下，因为我们有大量的存储过程，视图等，所以作为迁移的一部分，我将不得不使用SQL脚本将它们保持在正确的版本并向下迁移我不认为是可能的。

我喜欢在Application_Start期间运行的想法是我可以为Azure构建一个单独的部署包，然后将其上传到暂存，并且将运行数据库迁移，这就是它，而不是感谢运行手动脚本，以及然后换成生产。

Answer 1

在Application_Start期间运行迁移可能是一种可行的方法。特别是在开发过程中。

然而，存在一些潜在的问题：

• Application_Start将花费更长时间，每次回收App Pool时都会运行FluentMigrator。根据您的IIS配置，这可能是一天几次。
• 如果您在生产中执行此操作，用户可能会受到影响，即在更改表时尝试访问该表将导致错误。
• DBA通常不会批准。
• 如果迁移在启动时失败会怎样？你的网站是不是很糟糕？

我的意见 - ＆gt;

对于拥有大量流量的网站，我更喜欢使用构建脚本，并且在更改数据库架构时可以更好地控制。对于一个业余爱好（或小型非关键项目），这种方法没问题。

Answer 2

我过去使用的另一种方法是让您的迁移不会中断 - 也就是说，您可以在任何代码更改之前部署迁移并使用现有代码。这样，代码和迁移都可以在95％的时间内独立部署。例如，您可以创建一个新的存储过程，而不是更改现有存储过程，或者如果要重命名表列，则添加一个新列。

这样做的好处是：

• 您可以在任何代码更改之前应用您的数据库更改。然后，您可以自由回滚任何重大代码更改或破坏迁移。
• 中断迁移不会使现有网站失效。
• DBA可以独立运行迁移。