如何在 django 中维护测试服务器和生产服务器的迁移文件夹？答案

【问题标题】：How to Maintain Migration folder for test server and production server in django?如何在 django 中维护测试服务器和生产服务器的迁移文件夹？
【发布时间】：2020-06-05 16:08:05
【问题描述】：

我已经处理这个问题很长时间了。我们公司有两台 django 服务器，一台用于测试目的，另一台用于部署目的，每台都有自己的数据库和迁移。

我最初的解决方案是简单地维护两个迁移文件夹：

-->migrations
-->migrations(P)

如上所见，migrations(P) 表示生产级别migrations，此配置主要用于测试阶段，所有迁移都与测试数据库相关，一些当我们处于生产模式迁移时，它会被交换到以下文件夹结构：

-->migrations
-->migrations(T)

在上述情况下，migrations(T) 与测试数据库相关，migrations 与生产级服务器相关。

这工作得很好，但有时当有来自其他开发人员的多个提交时，我自己也在处理它，因为交换迁移文件的文件夹被合并并弄乱了导致崩溃。

对不起，如果我的问题有点令人困惑。任何维护生产和测试级别数据库迁移的替代建议或方法都会有所帮助

【问题讨论】：

为什么测试数据库和生产数据库需要不同的架构？我假设它们具有相同的结构。
嗯，我觉得还是单独创建一个test分支，把migration文件夹放到gitignore中比较好，这样在将代码迁移到生产环境时，不会更新生产环境的migration文件夹。

标签： python django django-models database-migration release-management

【解决方案1】：

一个应用应该只有一个迁移目录。您的发布管理流程需要更加健壮，以防止覆盖迁移。这可能会在代码合并到 master 或其他一些稳定类型分支之前在代码审查中发现。审阅者应该注意到迁移被删除并提出问题。

现在关于如何管理多个开发人员进行不同且可能相互冲突的迁移的测试数据库。您需要作为一个团队进行沟通并注意细节。对于 95% 的情况，迁移需要是可逆的。如果迁移不是，则该开发人员需要将其传达给其他开发人员，它正在登台并控制它，直到 A）它被部署或 B）测试数据库从生产中分叉或从之前的备份中恢复迁移。

沟通的另一部分是确定谁在使用测试环境，并确定您的分支中是否有应用的迁移。在部署您的分支之前，您需要反转那些其他迁移。然后，您可以安全地部署代码并运行迁移。这就是为什么可逆迁移非常重要的原因。

一个困难的部分是当迁移确实合并到 master 时，任何具有依赖于新合并迁移应用程序的迁移的开发都需要通过 makemigrations --merge 合并，或者它们可以重命名为 count 并更正它们的依赖关系。

如果您的组织很难通过不成文的规则来做这些事情，那么听起来您需要围绕您的版本实施一些更严格的流程。使您的数据库与迁移不同步可能是一个难以解决的问题。当它在生产数据库上并导致客户面临问题时，情况尤其糟糕。您的组织需要通过发布管理有效地管理其风险。

【讨论】：