SVN結賬或出口生產環境？

Question

在我正在開展的項目中，我們在開發團隊之間進行了持續的討論 - 生產環境是作為SVN存儲庫的結賬部署還是作為導出進行部署？

開發環境顯然是一個結賬，因為它不斷更新。 對於制作，我個人會檢查主干，因為它使未來的更新更容易（只需運行svn update）。 然而，一些開發人員反對它，因為svn使用svn進程的組/所有者和權限創建文件（這是在Linux操作系統上，所以那些事情很重要），並且在生產中也有.svn目錄似乎他們有點臟。

此外，如果是結帳 - 如何在不包含開發代碼的情況下將單個功能推送到生產中？ 你是否為每個功能使用標簽或分支？ 任何替代品？

編輯：我可能不太清楚 - 其中一個要求是能夠始終能夠將修復程序推送到生產環境。 我們希望避免完整構建（比簡單更新需要更長的時間），僅用於推送關鍵修復。

Answer 1

Subversion FAQ似乎主張將部署作為結帳，並使用提交后的鈎子腳本進行自動更新。 它們通過在httpd.conf中添加以下內容來阻止Apache導出.svn文件夾（可能是個好主意）：

# Disallow browsing of Subversion working copy administrative dirs.
<DirectoryMatch "^/.*/\.svn/">
    Order deny,allow
    Deny from all
</DirectoryMatch>

我自己也是新手，但也許你可以在創建一個新標簽時觸發一個鈎子腳本。 這樣，當您准備好更新實時網站時，您只需將最后一次更改提交到主干，創建新標記，腳本將使用svn update更新您的實時網站。

Answer 2

我一直在努力解決這個問題，我想我終於決定結帳了。 是的，那里有額外的垃圾，但......

• 導出不考慮已刪除的文件（除非您的解決方案是刪除目錄和THEN導出中的所有內容，我認為這更糟糕）。 Checkout將刪除已刪除的文件。
• 結帳速度更快。 期。 更新的文件越少意味着更少的下行/轉換時間，導出下拉並覆蓋一切，而不僅僅是需要更新的文件。

不是說這對每個人都有效，但這兩件事影響了我的決定。 祝你好運。

Answer 3

恕我直言，您應該創建一個分支/標簽，其中您擁有用於生產的dev env的（所需）子集。 有人應該手動維護或使用腳本自動維護。 然后，您應該導出（而不是結帳）。 增量更新不是問題，除非您要更改生產環境中的文件，並且不希望覆蓋這些文件。

只需我0.02美元

Answer 4

沒問題 - 出口。

您不會進行更新，因此沒有理由進行結帳。 你只是要部署垃圾。

我想說任何環境應該只是出口; 您只在開發時使用本地結帳。 當然我們也在使用構建腳本，因此更新部署就像運行腳本一樣簡單。

就開發代碼而言，為正在進行的任何工作創建分支。 只有在准備好部署到開發環境時才提交到主干。

Answer 5

我會研究像Capistrano這樣的部署軟件（這是一個紅寶石程序）

我個人會使用導出標簽的trunk副本，而不是只是導出trunk，如果你打算使用自己的解決方案或手動。

Answer 6

以下是一些意見 -

生產中的.svn文件很臟？ 如果.svn目錄完整而且沒有損壞，它們遠非臟，它們實​​際上是救命稻草。 為了安全起見，您可以告訴apache以防止瀏覽它們。

結帳或出口？ 我的方法......我絕對使用標簽和分支 - 將生產服務器連接到主干並且祈禱沒有人在有人將錯誤的代碼提交到主干之后運行svn以查看它在DEV上的作用是危險的。 我有一個可重復使用的標簽（比如_production和_staging），在我的設置開始時，我會將每個標簽檢出到匹配的服務器。 然后我鎖定所有訪問權限以修改live和staging服務器的內容。 此后，DEV服務器連接到主干頭。 當代碼足夠穩定以進行QA / staging時，我們創建一個標記並將其重命名為_staging，以允許登台服務器在看到對該標記的更改時同步到它（腳本運行'svn up'）。 一旦我們對_staging感到滿意，我們將其重命名為_production，並使代碼部署到實時服務器。 或者，您可以創建具有不同名稱的標記/分支，並使用“svn switch URL”將服務器指向新標記/分支（固定點）。 以上所有內容使得部署非常容易，無需停機，如果需要回滾，您可以快速重命名已存檔的舊標簽或使用'svn switch OLD_URL'立即撤消新的更改，而無需擔心每個小文件和行更改。

權限和所有權如果您了解並了解文件的權限，則可以在每次部署后運行腳本，以將CHOWN和CHMOD設置為您希望的結果。

恐懼與知識我聽說過很多害怕人們在生產服務器上排除SVN的存在。 相反的是實際上非常可怕。 如何確保您的產品團隊和客戶不會崩潰成大堆或錯誤消息而無法執行干運行或'svn status -u'以確保部署只修改那些需要的文件更改？ 檢查狀態讓我甚至知道是否有人強迫他們這樣做並直接在服務器上進行“快速更改” - 你知道人們傾向於繞過那些看起來很快的事情的規則。

成像在實時服務器上有錯誤？ 使用.svn，您可以確定與其同步的確切版本（svn info），然后檢查該URL是否為真（sv status -u）。 然后，您可以通過將相同的標記/版本簽出到沙盒服務器來構建該設置的誠實副本，您可以在其中安全地進行故障排除。

Answer 7

我將其部署為副本。 當然不是手動的。

我使用'make'和'checkinstall'。 我創建了一個小的Makefile，它使用系統命令'install'將所有需要的文件復制到Web服務器上的相應目錄中，並且我有預安裝和postinstall shell腳本將在服務器上運行。

當部署時間到來時，我只運行'checkinstall'創建一個包（RPM，DEB或TGZ，具體取決於我所針對的Linux發行版）。 我使用Linux發行包管理器（rpm，dpkg，pkgtool）提供的常規工具安裝它。 當然，如果你想跟蹤依賴關系，你可以使用yum，apt-get等。

如果您想要分發新版本的Web應用程序，這將非常容易。 到多個目標服務器。 卸載，恢復到舊版本等內容非常簡單，因為您為部署的每個版本都准備好使用軟件包。

如果你使用一些需要編譯的東西，這可能不適合你的“常推”策略。 但是，對於腳本編寫的東西（比如我做的PHP），在我的機器上創建一個包（大約300多個PHP文件）大約需要20秒。 並且可以在任何目標系統上安裝它。

要將代碼'for release'與'in-development'代碼分開，我使用分支。 使用Git，它非常簡單，因為分支便宜且快速。

Answer 8

就個人而言，我總是對這個問題的解決方案存在疑問，我更喜歡在我的生產環境中沒有“.svn”目錄，它非常臟，但與此同時，導出對於大型Web應用程序來說非常繁瑣（特別是如果使用一些第三方“組件”，如Extjs，FCKeditor等。）。

我認為目前還沒有“殺手級解決方案”。

Answer 9

讓我看看..... ln -s？ 什么可以用於？

/var/www/www.my-prod-site.com/public/
/var/www/www.my-prod-site.com/builds/Rev 1/
/var/www/www.my-prod-site.com/builds/Rev 2/
/var/www/www.my-prod-site.com/builds/Rev 3/
/var/www/www.my-prod-site.com/builds/Rev 99/

svn導出到你的構建directorys ......復制來自/ public的任何配置文件，這是你以前的發布版本的符號鏈接，然后只需將符號鏈接從public轉移到指向你的新構建目錄。 這需要時間的離線比任何我見過張貼在這里的東西少，也使得通過改變表WAY更快，除非你回去˚FCK P你的數據庫每次。

Answer 10

出口

而已。 你沒有任何理由把額外的垃圾放入生產系統。

• 您將公開您的源代碼
• 如果這是Web應用程序，那就更糟糕了，您的訪問者可以下載您的源代碼，這有多酷！ 非常開放:)