想象一下,基於雲計算的解決方案中,部分代碼的很大一部分是在內部開發的。我的問題是使用工件庫作爲內部代碼的地步,您可以始終直接從源代碼構建任何版本?用於內部代碼的神器存儲庫點
換句話說,在構建服務器上花費時間以促進緩解pf從代碼構建所需的構件版本vs添加像Nexus這樣的構件庫以將構建構件提供給部署?
想象一下,基於雲計算的解決方案中,部分代碼的很大一部分是在內部開發的。我的問題是使用工件庫作爲內部代碼的地步,您可以始終直接從源代碼構建任何版本?用於內部代碼的神器存儲庫點
換句話說,在構建服務器上花費時間以促進緩解pf從代碼構建所需的構件版本vs添加像Nexus這樣的構件庫以將構建構件提供給部署?
在理論上是的,如果你可以是進入一個工件在這樣的檢查的來源一定
編輯實際上,正如Mark O'Conner所指出的那樣,即使這樣兩個版本通常也不會完全相同,因爲它們通常包含時間戳和校驗和,具體取決於前者。你將不得不以某種方式在構建過程中手動修復它們,或者以某種方式在構建計算機上準確地重現時間和時間。
否則,您可能會遇到無法(完全)重建某個工件的情況。我寧願將所有發佈的內容都存儲在安全的地方。
的Continuous Delivery書呼籲建立一個二進制不止一次的反模式的做法:
此反模式違反了兩個重要原則。首先是 保持拆遷渠道的有效性,因此團隊儘快得到反饋爲 。重新編譯違反了這個原則,因爲它需要時間,尤其是在大型系統中。第二個原則是 總是建立在已知聲音的基礎上。這讓 部署到生產環境的二進制代碼應爲那些去 通過驗收測試過程中,確實在很多管道 IM-plementations,這是由存儲散列的二進制文件在 時檢查完全一樣的,他們在過程的每個後續階段創建並驗證二進制文件是否相同 。
通過散列值進行二進制相等性檢查對於高度管制域中的審計目的也很重要。
每次重建相同的修訂版時,生成的文件都有不同的文件校驗和。這使得不可能完全確定相同的修訂已經部署到兩臺不同的機器上。重用工件存儲庫中的相同二進制文件解決了這個問題。其次,開源項目通常會發佈一個包含源代碼以及發佈的工件的jar。這使第三方能夠驗證原始開發人員發佈(和簽名)的源代碼和二進制文件。 –