什麼是源代碼管理中多語言項目的合理結構？

在工作中，我們正在開發一個具有不少前端，後端和支持組件的大規模應用程序。通常前端是用C＃開發的，而後端是用Java開發的，儘管後端的一部分也是用C＃開發的，也可能是後來的C++。什麼是源代碼管理中多語言項目的合理結構？

語言和平臺的選擇不是任意的;我們試圖衡量每個開發時間的相對優點，工具鏈成本，特定開發團隊對語言的熟悉程度等等。但是，所有這些組件的共同之處在於它們都是完整操作所需的產品，並且他們正在由獨立（但高度溝通）的團隊同時開發。

此前，我們使用Team Foundation Server來處理我們的.NET代碼和Subversion來處理我們的Java代碼;由於團隊責任明確分開，除了將源代碼樹中生成的二進制文件（在這種情況下爲WAR）帶來的不便之外，這導致了很少的問題，以及保持分支和修訂同步的高昂手動開銷。通過這個項目，團隊之間的分離程度有意地小得多，並且分支/合併的數量預計會更高;因此我們正在轉向統一的VCS，更具體地說是Subversion。

這讓我想到了這個問題的肉：如何有效地混合Java和C＃代碼？實際上，我們將使.NET代碼依賴於Java代碼庫; Java二進制文件需要運行除單元測試代碼以外的其他任何東西（集成測試已經要求二進制文件，QA，驗收測試等等）。我們目前的想法如下：

 
/trunk 
    /java 
     /component1 
     /component2 
     /library1 
     /library2 
    /net 
     /assembly1 
     /assembly2 
     /... 
     project.sln

這個想法是整個源碼樹放在一個分支下; .NET代碼依賴於Java代碼，因此我們將爲該解決方案添加一個後構建步驟，該解決方案很可能會爲Java組件調用ant腳本。這允許分支整個代碼庫（對於.NET開發人員）或僅對Java組件（對於Java開發人員）進行分支。

這種解決方案的問題是：

當兩個代碼庫中的一個變成如此之大，使得它的副本爲每個分支得到不切實際的，會發生什麼？（我們的想法：將.NET和Java代碼拆分爲獨立的存儲庫，並使用svn：externals，對此的任何輸入將會被大大地提升讚賞）。
我們使用Eclipse進行Java開發。我們如何管理「共享」工作空間（即哪些項目需要哪些組件，依賴關係圖等）？到目前爲止，我們已經擁有相對較少的Java組件，所以每個開發人員都可以同時將它們全部保留在工作區中。隨着Java組件和Java開發人員的增加，我看不到我們如何繼續這樣做;關於如何保持工作空間版本化（la解決方案文件）的任何建議，同時仍保持兩個代碼庫之間的同步？

我很想聽聽您的意見！

來源

2009-04-30 Tomer Gabel

我們最終去與上述解決方案。分支機構的創建/結賬時間確實很長，但並不可怕（因爲我們轉向了更薄的分支模型）。由於我們還沒有找到一個體面的替代品，這就是我爲類似團隊推薦的結構。 – 2010-02-22 15:05:49

1：我發現最好按組件分組，而不是按語言分組。如果一個組件需要幾種界面語言，則仍然需要開發，測試和發佈它們。因此，將組件分成幾個回購站是而不是的一個好主意。

如果代碼的一部分緊緊依賴於另一部分，請將它們放在一起。更好地將各個組件分解到各個回收站（這甚至也適用於內部結構，其中，尤其是萬物生長，但如果按類型打包的東西，而不是功能，即在MVC，不必爲每個類別三個巨大的包很困難，而保持FooView，FooModel和FooController的緊）

SVN：外部組件可能的工作，並與後來的版本，我認爲可以用「內部」，即鏈接到其他迪爾斯在同一回購。這比管理單獨的回購更容易，尤其是標籤和分支。（戰慄）

2：你總是可以有開發商設置不同的工作區，或者使用工作集。與OS變體相比，商業Eclipse版本更好地支持共享工作區設置。（沒試過，只是工作，受到挫折與操作系統之一）

我做了C++（MSVS）和Java（Eclipse中）在一個回購協議，它工作得很好。同樣也是C++/Python。確保你的構建系統支持構建和測試一切（即使你的IDE只構建一個部分）。

來源

2009-04-30 17:52:00 Macke

我們的組件通常僅由一種語言組成;一個服務器組件用Java編寫並託管在Tomcat中。通常情況下，我們有一個用.NET編寫的瘦客戶端層來與它進行交互，並且幾乎不會改變，但我一定會將您的建議帶到桌面上，謝謝！ 2.我會試着看看商業的變體，然後，但如果是這樣的方向，我們去，我們可能會考慮IDEA更嚴重。再次感謝！ – 2009-04-30 22:44:00

什麼是源代碼管理中多語言項目的合理結構？

回答

相關問題