【问题标题】:Should Django migrations live in source control?Django 迁移是否应该存在于源代码控制中?
【发布时间】:2015-05-12 15:45:39
【问题描述】:

正如标题所说...我不确定Django migrations 是否应该存在于源代码控制中。

为:

  • 如果它们被意外从我的本地计算机中删除,那么下次我想运行迁移时就会出现问题......对吗?所以拥有它们对我很有用。

反对:

  • 第一次设置项目的开发人员不需要运行它们,他们可以直接从模型文件中工作。
  • 它们看起来像是特定于机器的杂物。
  • 他们会不会泄露我不想要的关于数据库的内容?

【问题讨论】:

    标签: django


    【解决方案1】:

    是的,绝对的!!

    来自docs

    每个应用程序的迁移文件位于该应用程序内部的“迁移”目录中,旨在提交到其代码库并作为其代码库的一部分进行分发。您应该在您的开发机器上进行一次迁移,然后在您同事的机器、暂存机器以及最终的生产机器上运行相同的迁移。

    重要的一点是,在将迁移部署到生产环境之前,应始终对其进行测试。你不应该在生产环境中创建迁移,只应用它们。

    您还希望将源代码管理中模型的状态与数据库的状态同步。如果有人拉出您的分支,必须找到错误并返回源代码控制的历史记录,他需要迁移文件来更改数据库的状态以匹配该时间点。如果他必须创建自己的迁移文件,它们将不包含中间状态,并且他会遇到模型与数据库不同步的问题。

    【讨论】:

    • 我正在努力解决同样的问题。如果两个开发人员分叉迁移历史,合并这些冲突可能会变得混乱。没有迁移,这些冲突就不会发生。对于 knbk 的第一点,只需在暂存环境中创建和测试迁移。对于 knbk 的第二点,这种担忧是真实存在的,但它似乎比迁移冲突更容易处理。
    • 我刚刚将我的第一个应用程序部署到 Heroku。尽管应用程序部署成功,但数据库迁移有一个 NodeNotFoundError,这是由于我的 Migrations 文件夹不在源代码管理中造成的。一旦我将迁移添加到我的 GitHub 存储库,我就能够将数据库迁移到 Heroku
    猜你喜欢
    • 2010-11-05
    • 1970-01-01
    • 2011-09-04
    • 1970-01-01
    • 2016-11-11
    • 1970-01-01
    • 2018-10-06
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多