Subversion：每個環境的分支？

我目前正在開發一個.NET項目，其中包含多個邏輯層和多個前端。這裏是我們的SVN結構的粗略表示：Subversion：每個環境的分支？

trunk 
---doc 
---lib 
---src 
------console 
---------console.vbproj 
------domain 
---------domain.vbproj 
------... 
------web 
---------web.vbproj 
---.sln

我們所有的一天到一天的發展，發生在軀幹 - 這是所有開發人員都籤/承諾。

我正在尋找一種乾淨而方便地部署環境（測試和生產）的方法。

我的想法是創建兩個分支，測試和生產，從幹線解決方案和所有。我證明這對我自己的原因如下：

我有過哪些修改流程完全控制其從主幹只合併到測試分支，從測試分支到分公司生產環境
我可以通過簡單地查看Subversion中相應分支的日誌，可以輕鬆查看在每個環境中執行的代碼。

有沒有人有類似這樣的解決方案的經驗？我缺少任何潛在的陷阱或疏忽嗎？

來源

2010-09-07 TMcManemy

爲了防止任何人仍然好奇，有幾篇關於這種方法的博客文章;只是谷歌「每次促銷分支」。我相信大部分材料都只是Jeff Atwood在2007年10月初次發表的文章的回顧：[see here]（http://www.codinghorror.com/blog/2007/10/software-branching-and -parallel-universes.html） – TMcManemy 2011-02-25 16:00:06

有沒有人有類似這樣的解決方案的任何經驗？

是:-)

是否有我失蹤的任何潛在的缺陷或疏忽？

隨着時間的推移，測試版本和發行版本將逐漸遠離開發環境，因爲您很可能不會合並來自幹線的所有更改。然後，開發人員將在稍微不同的環境中工作，並通過保持分支同步來浪費大量時間。這就是所謂的merge-mania anti-pattern。

我寧願建議從每個計劃版本的trunk中創建一個版本分支，一旦您獲得了實現的所有功能。當時你的分支都是平等的。然後有一個團隊來穩定和測試發佈分支。發展在主幹上並行發展。一旦您的版本被打磨，將修復程序合併回主幹。

對每個版本重複該過程。這樣你就可以限制合併的數量，並讓人們始終處於最前沿。

我希望這些方面能夠幫助您做出決定。該鏈接還顯示了許多其他反模式。閱讀所有這些內容，也許你會認識到一些經驗教訓，並會得到一些提示，以更好地解決它。

來源

2010-09-07 21:53:27 jdehaan

使用「分支每版本」方法，您將如何去實現自動化部署？例如，使用「每個環境的分支」，我可以構建腳本，以便每個分支都被編譯並部署到各自的環境中。然後，部署就像合併到我想要的分支並運行相應的腳本一樣簡單。 – TMcManemy 2010-09-08 12:48:07

也許我不明白你的意思是什麼。通常如果有一個共同的核心，你會切換（或外部svn：外部）特定於環境的代碼。所以不需要合併。如果您可以運行腳本來執行合併，那麼在您的設置中一定會有一些概念錯誤。合併是一項無法自動完成的增值工作。如果可以實現自動化，則不會增加任何值，因此在您的情況下可能只是不必要的開銷。 – jdehaan 2010-09-08 19:33:27

Upvote向我介紹「合併躁狂症」一詞。這導致了許多反分支模式。謝謝jdehaan。 – granadaCoder 2012-09-21 23:17:04

我們使用相同的佈局沒有任何問題。確保使用最新的svn版本。不應使用1.5之前的版本，因爲缺少合併跟蹤。

與來自atlassian的jira等錯誤跟蹤工具一起使用（我沒有贊助），您的設置變得更加透明。

來源

2010-09-07 21:39:07 zellus

Subversion：每個環境的分支？

回答

相關問題