1

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

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

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

编辑：

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

我喜欢在 Application_Start 期间运行的想法是，我可以为 Azure 构建一个部署包，然后将其上传到 staging 并且数据库迁移将运行，就这样，而不是感谢运行手动脚本，然后只需交换投入生产。

4

2 回答 2

1

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

这样做的好处是：

  • 您的数据库更改可以在任何代码更改之前应用。然后，您可以自由回滚任何破坏性代码更改或破坏性迁移。
  • 中断迁移不会关闭现有站点。
  • DBA 可以独立运行迁移。
于 2014-09-08T20:06:23.253 回答
1

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

但是也有一些潜在的问题：

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

我的意见->

对于流量相当大的网站，我更希望有一个构建脚本，并在我更改数据库架构时更好地控制。对于爱好（或小型非关键项目），这种方法会很好。

于 2014-09-08T08:53:33.657 回答