如何版本控制構建工具和庫？

Question

將您的編譯器，庫和其他工具納入您的源代碼管理系統本身的建議是什麼？

在過去，我遇到了一些問題，雖然我們有所有的源代碼，但構建產品的舊版本是一個急於嘗試獲取Visual Studio，InstallShield和其他工具（包括正確的補丁版本）用於構建產品。在我的下一個項目中，我希望通過將這些構建工具檢入源代碼控制來避免這種情況，然後使用它們進行構建。這也可以簡化建立新機器的工作 - 1）安裝我們的源代碼控制工具，2）指向正確的分支，3）構建 - 就是這樣。

選項我已經考慮包括：

• 複製安裝光盤ISO到源代碼控制 - 雖然這提供瞭如果我們回到舊的版本中，我們所需要的備份，這是不是一個好「實時」使用選項（每個構建需要從安裝步驟開始，可以輕鬆將1小時構建轉換爲3小時）。
• 安裝軟件源代碼控制。 ClearCase將你的分支映射到一個盤符;我們可以在該驅動器下安裝該軟件。這不考慮安裝工具的非文件部分，如註冊表設置。
• 安裝的所有軟件和設置構建過程在虛擬機中，存儲虛擬機的源代碼控制，並找出如何讓虛擬機在引導做一個版本。儘管我們很容易捕捉到「構建機器」的狀態，但是我們獲得了虛擬機的開銷，而且它無法幫助「爲開發人員提供相同的工具」。

這似乎是配置管理的一個基本概念，但我一直無法找到如何做到這一點的任何資源。有什麼建議？

Answer 1

我的組織具有「只讀」的文件系統，這裏的一切投入和版本。發佈鏈接（基本上是符號鏈接）指向您的項目正在使用的版本。當新版本出現時，它只是添加到文件系統中，並且可以將符號鏈接放到文件系統中。有完整的符號鏈接審計歷史記錄，您可以爲不同版本創建新的符號鏈接。

這種做法在Linux上的偉大工程，但它並不適用於Windows的應用程序，往往喜歡用的東西本地的機器，如註冊表來存儲配置一樣的東西這麼好。

Answer 2

我認爲VM是您的最佳解決方案。我們總是使用專用的構建機器來獲得一致性。在舊的COM DLL地獄時代，在安裝了非開發軟件（Office）的地方依賴於（COMCAT.DLL，任何人）。前兩個選項不能解決任何共享COM組件的問題。如果你沒有任何共享組件的問題，也許他們會工作。

開發人員沒有理由不能在同一個虛擬機的副本上進行調試。如果體系結構中有許多物理層，比如郵件服務器，數據庫服務器等，則問題會更復雜。

Answer 3

您是否正在使用像NAnt這樣的持續集成（CI）工具來完成構建？

爲.NET例如，您可以指定每個構建特定的框架。

也許流行的CI工具，無論你正在開發的有自己的選擇，讓你避免你的版本控制系統中存儲數的IDE。

Answer 4

我肯定會考慮圍繞這個想法的法律/許可問題。根據工具鏈的各種許可證是否允許？

你有沒有考慮鬼影新開發的機器，是能夠建立版本中，如果你不喜歡一個VM圖像的想法？當然，保持運行的硬件變化是幻影圖像可能會更麻煩比它的價值......

Answer 5

這是這是非常具體的環境。這就是爲什麼你不會看到一個指導來處理所有情況。我工作過的所有不同的商店都有不同的處理方式。我只能給你我對我認爲最適合我的看法。

• 建源控制下的新工作站 在 應用需要將所有的東西。
• 保持較大的 應用程序脫離源代碼管理， 像IDE，SDK和數據庫 引擎的東西。將這些文件保存在ISO文件的目錄中。
• 維護一個帶有源代碼的文本文檔，其中包含構建應用程序所需的ISO文件列表。

Answer 6

在很多情況下，您可以強制您的構建使用已簽入到您的源代碼管理中的編譯器和庫，而不是依賴於將來無法重複的全局機器設置。例如，使用C＃編譯器，您可以使用/ nostdlib開關並手動/引用所有庫以指向簽入到源代碼管理的版本。當然，也要將編譯器自己也編譯爲源代碼管理。

Answer 7

在我自己的問題的後續行動，我碰到在回答另一個問題引用this posting。雖然更多的討論這個問題比aswer，它確實提到了VM的想法。

Answer 8

至於「搞清楚如何建立在啓動」：我用一個構建農場系統自定義創建一個系統管理員和一個開發發展很快。構建從站查詢taskmaster是否有合適的排隊構建請求。這很好。

的請求是「合適的」用於從屬如果工具鏈的要求相匹配的從機的工具鏈版本 - 包括什麼操作系統，因爲該產品是多平臺和構建可以包括自動測試。通常這是「當前的藝術狀態」，但不一定是。

當奴隸是準備建，它只是開始投票的工頭，告訴它有安裝了什麼。它不必事先知道它預計會建立什麼。它獲取一個構建請求，告訴它要檢查某些標記出SVN的，然後從這些標籤中的一個運行一個腳本來把它從那裏。開發人員不必知道很多構建奴如何可用，他們叫什麼，或者他們是否很忙，只是如何添加到構建隊列的請求。構建隊列本身是一個相當簡單的Web應用程序。所有非常模塊化。

奴隸不一定是虛擬機，但通常是。從站（與物理機，他們正在運行的）的數量可以擴展到滿足需求。奴隸顯然可以隨時添加到系統中，或者在工具鏈崩潰時加入。這實際上是這個方案的主要觀點，而不是歸檔工具鏈狀態的問題，但我認爲這是適用的。

根據需要多久需要一箇舊工具鏈，您可能希望構建隊列能夠根據需要啓動虛擬機，因爲否則某個想要重新創建舊構建的用戶也必須安排合適的從屬服務器出現。這並不是說這一定很困難 - 這可能只是一個在他們選擇的機器上啓動正確VM的問題。

Answer 9

對圖書館的版本控制系統的versionning剛一說明：

• 這是一個很好的解決方案但它意味着包裝（即減少庫的文件的數量降到最低）
• 它沒有解決'配置方面'（即「我的'3.2'項目需要什麼特定的一組庫'）。
  不要忘記，隨着項目的每個新版本都會發生變化。 UCM及其「複合基線」可能會爲此提供答案的開始。
  • 你不想通過網絡訪問您的庫（比如雖然動態視圖），因爲編譯時間是：因爲

  的包裝方面（文件的最小數量）是非常重要的比使用本地訪問的庫文件時長得多。

• 你確實想要在磁盤上獲得這些庫，這意味着快照視圖，這意味着下載這些文件......這是你可能會喜歡你的庫的包裝：你需要下載的文件越少，你越好;）