跨項目管理和版本控制公共庫

Question

我們公司有很多解決方案。他們中的大多數人正在使用一組用於不同功能的通用庫（日誌記錄，緩存，數據訪問）。

我的問題是你如何確保他們得到妥善管理？

參考跟蹤項目直接從Windows APP1

優點：你不必合併和分支。

缺點：您可以在重新編譯代碼時在系統中引入問題。從現在起它正在編譯最新版本。

分支爲每個項目跟蹤併合並它們每隔一段時間 利弊是第一選擇完全相反。

我可能完全沒有想法，但我相信必須有更好的方法。

Answer 1

我們在這裏所做的只是不斷更新和改進我們的通用庫，然後當我們得到一個我們感到滿意的點，並且需要在應用程序中使用它時，我們將主要或次要版本根據更改數量，爲其構建安裝程序，並將其標記在源代碼管理中。

我們需要對該應用程序進行更改時，通過將其升級到最新版本來處理舊應用程序。

我爲通用庫構建SDK和Redistributable安裝程序。 SDK包含所有開發人員，包括源代碼，模板，文檔，將DLL放在驅動器上，並將DLL放入其GAC中。可再發行組件簡單地將這些DLL放入GAC中。我們在服務器上安裝可再發行組件。

我們很快就會去找一種方法，在這種方法中我們不會生成一個可再發行組件。我們只會生成一個SDK，並且在該SDK中將成爲公共庫的合併模塊。當開發人員使用該庫並準備將其應用程序移至生產環境時，他們將爲其構建安裝程序並在該安裝程序中包含合併模塊，這樣應用程序的部署始終具有正確版本的公用庫，而我們不必擔心首先將其安裝在服務器上。

我對你的環境一無所知，所以我不知道這些技術是如何爲你工作的，但它現在對我們來說工作得非常好。

Answer 2

要做出的一個重要區別是，如果服務器上的兩個子項目運行不同版本的「共享」代碼，那麼它是否很重要。圖書館，你可能沒問題。共享服務？可能不會。如果是後者，那麼分支變得更加棘手，因爲每個人都很容易失去同步。如果你可以負擔得起並行運行不同的版本，那麼我會選擇分支方法，因爲它可以讓每個項目/區域更好地控制何時接受更改。

您沒有提到的一個選項是將常見項目的二進制文件存儲在源代碼管理中，並使用二進制引用。這與第二個選項（分支）具有相似的屬性。與直接引用項目相比，問題少，因爲只有已知好的（或至少可編譯的）版本可用。其中一個缺點是，編輯共享項目並行使用它可能會有點痛苦。

這也有助於避免您的大型解決方案混亂。

你也可以用這個設置做一些聰明的事情，比如在你的共享項目上用一個自定義後期構建任務設置一個CI構建來檢查新的二進制文件。