azure - FluentMigrator 从 Application_Start 迁移

Question

我目前正在更改我们的数据库部署策略以使用 FluentMigration，并一直在阅读如何运行它。有些人建议它可以从 Application_Start 运行，我喜欢这个想法，但其他人说不，但没有具体说明原因，所以我的问题是:

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

如果有人了解其他人如何在部署期间处理数据库迁移，特别是从部署到 Azure 云服务的角度，我将不胜感激。

编辑:

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

我喜欢在 Application_Start 期间运行的想法是，我可以为 Azure 构建单个部署包，然后将其上传到暂存区，然后运行数据库迁移，仅此而已，而不是运行手动脚本，并且然后只需切换到生产环境即可。

Answer 1

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

但是存在一些潜在的问题:

• Application_Start 将花费更长的时间，并且每次回收应用程序池时都会运行 FluentMigrator。根据您的 IIS 配置，这可能一天会发生几次。
• 如果您在生产中执行此操作，用户可能会受到影响，即在表发生更改时尝试访问表将导致错误。
• DBA 通常不会批准。
• 如果迁移在启动时失败会发生什么情况？那么您的网站瘫痪了吗？

我的意见 ->

对于具有相当大流量的网站，我希望有一个构建脚本，并在更改数据库架构时进行更多控制。对于业余爱好(或小型非关键项目)，这种方法就很好。