您是否將構建放入源代碼庫？

Question

我想對這個想法得到一些反饋，因爲我可以看到每種方法的優點和缺點。 作爲一名Java開發人員，這將是將jar文件存儲在代碼庫中，但它可以很容易地擴展到其他編譯語言。

優點：

• 可以輕鬆地檢索以往的分佈，而不需要依賴於（potientially不再可用）過時的工具來重新編譯。

缺點：

• 可以迅速 「膨脹」 的代碼庫，取決於建立的頻率。

Answer 1

我們將版本歸檔到目錄結構中，並在源代碼管理中標記適當的版本。這使我們可以訪問生成它們的內置版本和源代碼。

這很容易使用構建腳本來自動化標記和存檔發佈版本。

Answer 2

妥協：將工具和源代碼存儲在存儲庫和標記構建中。通過這種方式，您可以隨時重新創建產品的任何版本。

而且，您始終可以爲編譯的工件提供單獨的存儲庫。

Answer 3

將特定的客戶版本放入存儲庫。
理論上這並不是必需的，因爲我們總是可以複製該版本，但能夠獲得在特定日期發送給某個客戶的確切.msi - 我們然後在一個乾淨的虛擬文件中進行測試。

一個原因是它可以保護您免受來自Windows或Visual Studio更新的構建環境之外的任何更改。如果msi本身已更新，您可能無法重現msi的位構建！

Answer 4

我認爲在版本控制系統中存儲構建輸出是合適的。既用於測試構建版本的某個特定版本，也用於緩解某些開發任務。

但是，您應該確保您還將所有存儲在存儲庫中，以便在需要時重新創建確切的構建。你應該使用consitent標籤/標籤來​​促進這一點。您可能需要使用不同版本的各種組件測試錯誤修復，並根據整個系統的複雜性，您可能需要嘗試不同的組合。

Answer 5

我們將標記存儲庫的任何版本，以便我們可以獲得任何內部版本號&的實際源代碼，然後我們壓縮並上傳實際部署的實際已發佈構建文件 - 只是爲了確保沒有偷偷摸摸的最後一分鐘配置在部署過程中進行調整等，這些都不會反映在幹線本身。

Answer 6

如果您可以創建一個足夠好的構建系統，僅通過檢出代碼就可以重新創建確切的構建，那麼我認爲不需要將構建存儲在存儲庫中。

對於我的大部分東西，我不存儲特定版本的代碼，但是我確實存儲了我的代碼依賴的特定版本的庫。我在幾個月前付出了很多努力，使得加載標籤和鍵入「ant」並且所有東西都可以正常構建，而不依賴樹之外的任何東西。 （不包括正確的javac和ant）

不幸的是，我們的一些代碼庫沒有一個好的構建系統（即，需要手動設置sdks並獲取各種外部庫和戳環境變量），這將是困難的根據存儲庫重新創建一個特定版本的構建版本（我們一直在向前推進，而不是真的支持舊代碼，所以開發人員的工作站設置得足夠接近，以至於我們還沒有被重新燒燬在我們目前的版本之前是一箇舊的分支），在這種情況下，我們確實存儲了我們發佈的版本（對於不可避免的胖手指「哦，不，我在錯誤的服務器上做一些測試」或者同樣陰險的東西）。

Answer 7

有時。大多數情況下，答案是沒有，但仍有一些情況，如果有意義的話，就這樣做。

順便說一下，我很驚訝，這仍然是開放的。這些討論類型的問題通常在不到5分鐘的時間內投票結束。

Answer 8

我不認爲有充分的理由來版本實際構建。標記源版本並使其成爲只有受控組才能訪問更改標記的權限。構建標籤不應該對它進行簽入，因此重建構建應該是微不足道的。

Answer 9

我將構建存儲在服務器上的文件夾中，並定期進行備份。但我標記代表該構建的修訂。在build文件夾中，我不僅存儲可執行文件，二進制文件或頁面（我們的案例是ASP.Net），還存儲了從SQL Delta獲得的更改腳本。

這些標籤的名稱與字段的標識符相同，因此如果您的版本爲「System_2009-07-30-01」，您將擁有一個帶有該名稱的標籤。因此，如果您需要修復某些內容，只需查看構建名稱，查看標記，然後查看所需的修訂版即可查看可能發生的情況。

Answer 10

爲了減輕舊構建工具可能無法在新環境中工作的擔憂，我們將我們的構建計算機映像歸檔爲主要版本。對我們來說很容易，因爲我們的構建機器是虛擬化的。這是計劃B，以防其他方式不起作用。

Answer 11

我想來源，依賴，二進制文件和構建工具應該進行版本在一起......這是跟蹤正在發生的事情與在最終版本來自多個源的項目大項目的唯一途徑...