在将项目部署到服务器之前重置所有迁移是一种好习惯吗？答案

【问题标题】：Is it good practice to reset all migration before deploy project to the server?在将项目部署到服务器之前重置所有迁移是一种好习惯吗？
【发布时间】：2021-12-05 12:38:40
【问题描述】：

我有两个关于部署最佳实践的问题，与迁移相关。

我正在开发一个 Django 项目。有时我必须更改一些以前的迁移，因为我以前的模型之一发生了一些变化（比如将其他模型具有 FK 的模型重命名为我知道解决方案，但它是肮脏和手动的）。有时它会产生很多冲突。

我想知道“当我不在生产环境时，是否真的有必要为解决此类冲突而烦恼？何时可以通过删除迁移文件并删除 SQLite DB 来重置所有迁移？”
在开发项目中包含许多迁移，这些迁移通过更改模型来纠正以前的迁移（迁移如重命名、添加列...）。第一次将项目部署到服务器时重置所有迁移并重新创建所有迁移不是更好吗？我认为为什么要在服务器上创建一个表，其中包含多次更改模型的迁移？为什么不应该只部署最终迁移？

我没有找到任何有关最佳实践的文档。非常感谢您与参考文献分享想法。

【问题讨论】：

不要重置迁移。您可以创建一个新的 git 分支，进行所有更改，如果一切正常，然后推送到主分支并进行一次迁移。

标签： python django deployment migration django-migrations

【解决方案1】：

我不确定 django 是否发布了有关迁移的最佳实践，因为它总是会给出“视情况而定”的答案。

根据我的经验，当您准备好开发项目时，我建议您将项目归零并重新创建所有迁移，这样您就可以从干净简单的历史开始。

也可以选择squash migrations，尽管如果您的历史记录是错误的或不相关的 - 我不确定您为什么要在项目中使用该历史记录。

【讨论】：

@chris 问题是关于新 django 应用程序的初始部署。不是后续的迁移。为什么要保留所有的开发历史？你真的需要你的全新项目知道你已经改变了 char 字段的 max_length 四次吗？这不是一种习惯，它是关于第一次部署应用程序。没有理由维护详细的迁移历史记录，当您最终压缩迁移时，这些历史记录无论如何都会被删除。
我不确定您是否真的阅读过这里的问题。这是关于将 django 项目第一次部署到生产环境中。将初始迁移与 CI/安全问题混为一谈对您的观点或这个问题没有价值。数据库中没有数据。没有习惯在这里形成。此步骤表示为您的应用程序创建一个干净的 0001_initial 迁移。你不能重构迁移......这没有任何意义。
显然不应随意破坏生产感知迁移迁移文件。但是，这个问题可以重述为：“如果开发应用程序的开发人员在开发过程中更改特定 CharField 的 max_length 4 次并生成四个单独的迁移文件，最好提交 4 个迁移文件，还是重新运行迁移以创建一个代表更改的迁移文件？”代表变化的 IMO 单一迁移文件是“Doing things the right way”。