大規模項目團隊持續集成歷程

　　這篇文章是我在兩年前寫的，記錄了一個150+人的軟件團隊(最多時近200人)如何在一個龐大的遺留系統上，通過逐步建立一個持續交付部署流水線，從而達到頻繁發布的狀態。最終在該團隊的持續交付基礎設施中，共有260臺服務器用于構建、測試和部署(幾乎全部是虛擬機)。而這個產品也可以每六周發布一次。

　　在大規模項目團隊中可能遇到的問題

　　對于小規模、短周期的項目來說，團隊與持續集成會相處地非常融洽。而對于大規模、長周期項目的初期來說，也不會有太多的問題。此時常見的也是基本的持續集成模式就是：Build->test->package。然而，只要時間稍長一點兒，持續集成就會發出壞味道了。此時的癥狀包括：

　　1. 作為開發人員

　　要等很長時間才能知道是否可以提交代碼了。如果你遵守“頻繁提交”的原則，那么百人團隊不間斷的提交，會使集成服務器一直處于繁忙狀態，而你不得不等待他人的build過了以后，才能看到自己提交的結果。

　　要等很長時間才能知道我的提交是否通過了;

　　如果build失敗了，要花很長時間才能知道是否和自己的修改相關;

　　既使提交了fix，也不知道自己的提交是否真的修復了這次構建;

　　構建經常處于失敗狀態。

　　2. 作為測試人員

　　測試人員不知道到哪里拿哪一次的構建產物來進行測試;

　　發布經理不知道當前各種各樣的測試部署環境中，到底部署了哪個版本，包括哪些新功能或修改的bug;

　　不確定在同一個構建里，所有組件的版本是否都是正確的;

　　3. 作為項目經理

　　不確定各個測試部署環境中的配置是否都與其上運行的構建相一致;

　　不確定測試人員測試的是否在正確的運行環境上運行了正確的版本;

　　4. 其他方面的問題

　　所有的安裝部署都需要手工操作。

　　以上這些問題會給你的發布管理帶來無限的問題和風險。那么，是否因為這種“持續鬧心”就放棄持續集成呢?回答當然是否定的。Do it more if it hurts you. 不要因問題的暴露而放棄，相反，應該歡呼。因為這反映了發布過程中的問題與風險，是時候解決它們了。

　　如何解決大規模項目中的持續交付問題

　　由于大項目本身的復雜性，其解決方案也不能一概而論。下面以某大型項目為例，介紹其中的幾個解決方法。

　　1、項目基本信息描述

　　該項目最初就試圖建立一個好的持續集成環境和基礎。由于是一個遺留系統，費了很大勁兒，才能夠得到可工作的軟件。然而，由于隊伍不斷壯大，而且環境也在不斷變化，持續集成很快就無法達不到其預期目標了。怎么辦呢?

　　項目背景:

　　項目是一個具有可配置性的Web 門戶產品，面向不同行業的市場，可自己定制門戶。該項目有一個遺留的代碼庫，而且可以肯定的說，在今后的一年半之內是無法擺脫這個遺留代碼庫的。而且，很多緊耦合的、不必要的臃腫代碼，同時根本不存在有價值的測試代碼?，F在我們在逐步地重寫代碼，但還是不能刪除它們，因為某些網站還要依賴于舊代碼。事實上，這是一個.NET平臺上基于SOA的網站。

　　開發團隊情況：

　　團隊是一個敏捷分布開發團隊(三地協作，均有開發人員，且有時差)。整個團隊有150多人，分成十幾個團隊，每個團隊都有一個完成的結構(BA/DEV/QA)，其中有一個是項目持續集成團隊(項目之初，大約有五六個人，工作負荷很大，項目運行一段時間后只要兩個人就足夠了)。使用SVN做版本管理工具，在Windows2003上使用NAT, MSbuild和batch腳本進行構建管理，最初使用CC.NET做為持續集成服務器，后來使用Cruise(Go)。

　　初始的持續集成環境：

　　上面所述的持續集成問題在項目一開始就出現了，因為該項目有一個龐大的遺留代碼庫，而且使用的基本持續集成方式(build->test->package)而且測試人員手工部署進行各類測試。

　　其初始的持續集成環境如下所示：

　　第一步目標：盡量減少團隊之間影響

　　方法：先化整為零，再化零為整 ————根據團隊劃分代碼(或者根據代碼劃分團隊)。

　　手段：DVCS+私有持續集成服務器+全局持續集成服務器

　　每個團隊都使用GIT做為中間源代碼管理工具。這樣，團隊人員可以先提交到GIT。每個團隊有自己的持續集成環境。一但構建成功，觸發將代碼提交到中心的源代碼庫，并觸發中心源代碼的持續集成。有一個專職團隊負責全局持續集成的結果跟蹤。

　　益處：

　　每個團隊都可以天天提交代碼 (如果這些代碼沒有讓自己的構建失敗，就說明至少能夠通過初步檢驗)。

　　任何一個團隊的構建壞了，并不影響整個項目，而只是一個團隊。

　　有一個專職團隊負責全局，不用每個團隊都停下來。

　　如果全局持續集成失敗了，不用所有的團隊停下。

　　第二步目標：提高反饋速度

　　方法：化整為零，再化零為整————測試分組運行。

　　手段：并行化與中心倉庫(Cruise的并行化與中心倉庫)

　　由于功能多且復雜，測試較多，運行很長。利用Cruise的并行化特點，每個團隊將測試分成28組。一旦提交后，Cruise會將其放在28臺機器上并行運行。運行后，將所有測試輸出和結果上傳到同一處(Cruise Server的中心倉庫)。

　　益處：1. 反饋時間大幅度縮短(原來30分鐘以上，現在20分鐘之內)。

　　2. 易擴展：如果因測試增多而導致反饋周期長，可通過增加更多的機器解決。

　　3. 易維護：對于測試分組和構建機器的增減來說，在Cruise中都非常容易，只要在同一處修改配置即可。

　　4. 易追蹤和Debug：所有的信息(包括artifacts)都放在同一處，能過Web訪問。

原文轉自：http://www.anti-gravitydesign.com