从Application_Start迁移FluentMigrator

时间:2014-09-07 08:40:48

标签: azure migration fluent-migrator

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

  1. 在应用程序启动时运行数据库迁移是不是一个坏主意,如果是这样,为什么?
  2. 我们计划将我们的网站迁移到部署到azure云服务,如果我们不从application_start运行迁移,我们应该如何/何时运行它,考虑到我们希望尽可能简化部署。 / LI>
  3. 在哪里运行它们如何确保它只运行一次,因为我们将拥有一个网站和多个工作者角色(尽管我们可以确保只从网站调用迁移代码,但将来我们可能会增加到2个或更多实例,这是否意味着它可以运行多次?)
  4. 我非常感谢有关其他人如何在部署期间处理数据库迁移的任何见解,特别是从部署到Azure云服务的角度来看。

    编辑:

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

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

2 个答案:

答案 0 :(得分:1)

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

然而,存在一些潜在的问题:

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

我的意见 - >

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

答案 1 :(得分:1)

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

这样做的好处是:

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