2017-04-01 51 views
0

我像往常一样将<project>/<app>/migrations文件夹添加到版本控制中进行部署。因为最近我还使用了django-auditlog,它在<project>/env/Lib/site-packages/auditlog/migrations中创建了自己的迁移。这些迁移适用于我自己的迁移。所以我想知道:我是否也应该将它们添加到VCS并部署它们?我应该如何处理插件创建的迁移?

回答

0

不可以。您不应该部署这些迁移。一般而言,您不应该部署任何第三方迁移。

原因很简单。第三方软件包在其migrations目录中进行了初始迁移。每次创建依赖于第三方软件包的迁移时,此迁移都将存在于您的应用的migrations目录中(不在包之内)。

所以,当你第一次部署你的代码和你的服务器上运行pip install -r requirements.txt,那么所有第三方软件包将被安装,当你做./manage.py migrate那么Django会看你的INSTALLED_APPS和执行所有迁移为每一个在此列表中。

与Django本身一样,任何第三方软件包也会发生同样的情况。假设你在requirements.txt文件中只有Django==1.10.6。当你将它部署到服务器并执行pip install -r requirements.txt,时,那么你的数据库将被所有内置的Django特定表(即auth,sessions,contenttypes等)“填满”,并在INSTALLED_APPS中启用设定清单。

唯一的一个,你应该部署是项目目录(requirements.txtmanage.pyrobots.txt等)下的一切,而不是你的第三方应用程序可以活多久你的项目中(下.virtualenv目录,可能)或在单独.virtualenv目录在您的项目之外。

与你的问题类似的是node_modules nodejs。 node_modules目录从未部署到VCS(因为它的大小可能相当大),而只有package.json,因为知道项目需要哪些依赖关系(package.json/requirements.txt),那么您的项目可以从零“重建”自己。

+0

感谢您的详细解答。这对我来说似乎是有道理的,但是您能否补充一点澄清:为什么我自己的迁移会有所不同?大概我们不相信Django可以在部署时始终正确地重建它们,所以它们应该受版本控制。然后,我们为什么信任Django的第三方应用迁移功能? – texnic

+0

您可能(或不是)版本控制您的应用程序的迁移,但不是第三方的。因为第三方应用程序存在于您的虚拟环境中(在'site-packages'目录下)。你不需要版本控制这个目录。在部署你的项目后,你运行'pip install -r requirements.txt'(注意这个文件下的每个应用都有一个版本号),并且安装了所有的第三方软件包(以及它们的任何潜在的迁移)。所以,你确定每个第三方都会在你的项目中应用正确的迁移。这是否为你澄清? –

+0

不:)这是有道理的,这也是我目前的做法。但是我错过了为什么我可以相信在安装第三方应用程序时会生成和应用正确的迁移,而不是在部署我自己的应用程序时。如果我理解正确,通过VCS部署我自己的迁移的想法是迁移不保证以我想用'manage.py makemigrations'创建的方式创建,所以我希望能够提前测试它们。我可以想象,例如管理网站的迁移生成是非常明确的和可靠的。这同样适用于第三方应用程序吗?这里的差异让我感到不安。 – texnic

相关问题