持續集成之“依賴管理”

　　在前文《分支策略(續)》中，我們討論了多組件應用程序的持續集成策略，即：為相對獨立的組件創建自己專屬的代碼庫，然后通過現代持續集成工具進行組件間的持續集成。Joe的團隊在首次發布之后，開始使用這種方式。然而，沒有多久，他們就遇到了一個問題：一次提交構建所花費的時間太長。

　　一天，Joe就早早地來到了辦公室。因為他前一天下班前，他開發的用戶故事還有一小點就完事兒了。他想利用早上這點兒時間把它搞完，交給測試人員進行測試。他修改了某個模塊的一段代碼，在本地構建測試通過以后，就提交了， 然后起身去樓下買些早點。十五分鐘后，他回到了電腦前，令他沮喪的是，這次構建還在進行最后的階段，即所有模塊集成測試和系統級測試。他只好又起身去沖了杯咖啡。然后，一邊看著屏幕上的構建進度條，一邊喝著咖啡。七分鐘后，構建終于成功結束了。雖然這是一次成功的構建，但總是覺得不爽，花了二十多分鐘才做完提交構建。于是，他開始仔細地查看起構建腳本和構建日志。

　　一、一次生成，多次復用

　　中午吃過午飯，他把Bob和Alice叫到一起，開始討論早上他遇到的問題。

　　“的確是非常煩人，現在構建時間太長了。”Alice說道。

　　“我今天早上查看了一下我們的構建日志，發現構建時間長的原因之一是：每種測試開始之前都要更新代碼，再重新編譯一次。”Joe說道。

　　Bob提出了一個解決方案，并畫在了白板上。“我們是否可以建立統一的產物庫，每次構建的產物都以一定的規則放在其中?這樣，后續的測試需要使用這些二進制產物的話，直接從產物庫中獲取即可。”(如圖1所示)

　　“聽上去不錯。然而，我們是否需要把每次構建中產生的內容都放入產物庫，這會非?？斓爻缘粑覀兊拇疟P空間。”Alice不無擔心的說。

　　“目前構建完成以后，所有的產物都放在那臺構建機器上。我們也遇到過因構建機器硬件問題或誤操作將所有重要歷史信息都丟失的事情。所以，我們至少需要備份。”Bob回答道，“另外，將每次構建的產物放在統一產物庫中，我們就可以解決Joe剛才提出的重復編譯問題。當然，我們需要有選擇地將重要的構建產物放到統一產物庫中，而不是所有內容。通過在每次構建后增加一個上傳任務，讓各小組將其認為有用的信息上傳到產物庫，比如構建日志、測試報告、構建后的二進制文件等。但一些臨時文件就沒有必要了。當然，這只能緩解產物庫膨脹的速度。盡管持續構建的次數非常多，但我們并不是需要一直保持所有構建的產物，所以，可以定期刪除那些沒有保留價值的構建產物，比如對那些重要構建的產物進行標記，其它的就可以刪除了。”

　　Alice和Joe都點了點頭，表示同意。但Joe的眉頭馬上又皺了起來。“嗯，好象這里還有點兒問題。”

　　“什么問題?”Alice和Bob同時問道。

　　Joe說道：“對于我們平臺中的一些小游戲組件來說，這沒有什么問題。因為它們的構建產物都不太大，網絡傳輸帶寬和速度都不是問題。但是，對于那些很大的二進制文件或測試數據來說，這么做的話，可能就有問題了。”大家都點了點頭，并開始思考這個問題。

　　忽然，Joe叫道：“不好意思，其實這不是個真正的問題。首先，我們的測試數據變化就不頻繁，原來也沒有放在產物庫中，而是放在了一個共享目錄中進行版本管理。所以，這部分在構建中的做法與之前沒有什么不同。其次，對于較大的二進制文件，只要在需要它的構建機器上把它緩存起來。那么在下一次構建時，構建腳本可以對這個本地版本進行驗證，如果版本正確且沒有被破壞(比如通過MD5驗證)就可以繼續使用。否則，就再從統一產品庫取出正確的文件將其覆蓋就行了。”

　　“這么做還有一個好處，而且是非常重要的好處。”Alice補充道，“我們的手工測試版本也可以從統一的產物庫中拿到，這就保證了自動化測試所有的二進制文件與部署到手工測試環境中的二進制文件是同一個文件了，也就不會出現因重新編譯時的環境不同而導致的不一致問題了。而當我們做上線部署時，也從這個統一產品庫中獲取，從而做到自編譯開始直到上線部署的二進制包的一致性啦。”

　　于是，Joe與團隊一起對其持續集成平臺和所有構建進行了改造，將其打造成了一個具有組織級產物庫的持續集成和發布管理平臺。他們不但有效地縮短了每次構建的時間，還可以輕松地通過產物庫追蹤到每個上線版本在代碼版本控制庫中的對應代碼，讓問題追查變得更容易了。

　　二、依賴管理

　　一個月后，根據市場的需求反饋，他們開發的一個游戲升級了，反應速度非?？?，效果非常好。但引申出來的一個問題是：游戲和平臺的升級頻率不一致，持續集成應該怎么做。對于Joe的團隊來說，是一個非常大的問題，因為他們的開發流程嚴重地依賴于持續集成平臺。于是，Joe和團隊的核心成員打算討論一下，如何應對目前這種情況。

　　在會議室的白板前，Joe畫出了當前所用的持續集成策略(如前圖所示)。

　　Bob說道：“到目前為止，我們已經發布了幾次，而且最近一次只發布了一個游戲應用。我們如何管理我們的發布流程呢?在我之前工作過的公司中，產品會有幾個版本，包括穩定版本、已對外發布或即將發布的版本、最新版本：用于公司內部測試。每當將要發布新版本時，就拉出一個分支，進行內部測試，并修復嚴重的缺陷。當沒有嚴重缺陷時，才能作為穩定版本公開發布。”

　　Alice答道：“對于單個的軟件交付產品來說，通?？梢酝ㄟ^“按發布拉分支” 的方式進行開發，正如我們最開始所使用的持續集成策略。但是，現在我們的游戲平臺與單個交付產品不同。我們有自己的服務器集群，只要測試覆蓋率及測試質量足夠好，測試速度足夠快，我們就可以通過小流量試驗部署后再大規模上線的方式進行發布?，F在，我們的問題是由于各個游戲組件的發布頻率各不相同，組件存在依賴關系，導致很難決定在持續集成過程中，到底應該使用哪個依賴版本。尤其是我們現在還有一個公共庫，被多個組件使用。”

原文轉自：http://kb.cnblogs.com/page/101101/