2017-04-01 58 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