【问题标题】:Are there any downsides to doing a schema migration in my post_compile script在我的 post_compile 脚本中进行模式迁移有什么缺点吗
【发布时间】:2012-10-16 15:25:40
【问题描述】:

我有一个在 heroku 上运行的 django 应用程序。我想在依赖于它们的任何代码上线之前运行我的 South 迁移。在快速查看当前推荐的做法后,我发现了两个建议的迁移程序。

建议 1

  1. 提交并推送所有更改
  2. 为每个应用运行heroku run python manage.py migrate <APP_NAME>

在步骤 1 和步骤 2 之间有一段时间,我的代码假设最新架构已到位,但数据库尚未更新。

建议 2

  1. 提交并推送所有数据库更改。
  2. 迁移。
  3. 推送所有代码更改。

这解决了之前的问题,但增加了部署过程的复杂性,总有一天我会搞砸的。

可能的解决方案?

似乎我可以避免建议 1 中的问题并且通过使用自定义 post_compile 脚本将我的部署保持在一个步骤中 为我的每个应用调用python $MANAGE_FILE migrate <APP_NAME>(按依赖顺序)。

我在任何地方都没有看到这个推荐,所以我的问题是双重的。您能看出这种方法有什么潜在的问题吗?您有更好的方法吗?

【问题讨论】:

    标签: django heroku django-south


    【解决方案1】:

    如果您的应用程序可以承受一些停机时间,我认为最简单的方法是

    1. 使用 $ heroku maintenance:on 暂停您的应用程序
    2. 使用heroku run python manage.py migrate 一次性迁移所有应用程序
    3. 重新启动您的应用程序:$ heroku maintenance:off

    够了吗?还是您有更复杂的需求?

    【讨论】:

    • 一点停机时间并不是世界末日,但如果可以避免它,我显然更喜欢这种方法。对于任何大的或向后不兼容的更改,我肯定会使用维护模式。
    • 我也希望对纯代码更改和代码更改 + 小架构更改具有完全相同的部署过程
    • 我明白,但我真的不认为您应该将较小的架构更改与“大更改”区分开来。对我来说,只要模式和代码同时发生变化,它们就应该从应用程序的角度自动执行。在绝大多数情况下,采取其他方式的成本(不一致的风险和/或增加更多的复杂性)超过了收益(没有明显的停机时间)。
    • 我不同意。例如,向表中添加一个额外的可为空列是比更改现有列的类型更安全的操作。前者将兼容旧代码和新代码,后者将破坏所有旧代码。无论哪种方式,我都希望我的架构迁移过程相同,唯一的区别是我将为后者打开维护模式,而不是前者
    猜你喜欢
    • 2014-06-15
    • 2020-04-07
    • 2011-01-21
    • 2021-10-06
    • 2016-12-24
    • 1970-01-01
    • 2011-06-29
    • 1970-01-01
    • 2019-10-05
    相关资源
    最近更新 更多