前些日子寫了關于小規模産品團隊的持續內建實踐 ，之後就一直就忙于項目，今天終于有時間完成這一篇關于大規模項目的持續內建相關問題了。
一、持續內建基礎
在典型的軟體項目中，內建階段一般都是在最後，是以也是出現問題最多，而且最有可能導緻不能按時傳遞。而持續內建（XP十二實踐之一）可以用來解決這個問題。既然大家都認為“頻繁地使軟體在某一代碼基線建構并通過測試”是個不錯的做法，那麼讓代碼每次變化時都能夠成功建構并通過測試不是更好嗎？
通過持續內建，所有的工作都會盡可能地內建到單一的代碼基線上。而每次代碼的送出都會觸發一次建構以及一系列的測試。是以開發人員可以得到及時的回報，并可以随時建構和測試。同時，還可以減少在軟體釋出之前的內建過程中可能出現問題。
二、大規模項目團隊中可能遇到的問題
對于小規模、短周期的項目來說，團隊與持續內建會相處地非常融洽。同時，對于大規模、長周期項目的初期，也不會有太多的問題。此時常見的也是基本的持續內建模式就是：Build->test->package。 然而，隻要時間稍長一點兒，持續內建就會發出壞味道了。此時的症狀包括：
1. 做為開發人員
A 要等很長時間才能知道是否可以送出代碼了
如果你遵守“頻繁送出”的原則，那麼百人團隊不間斷的送出，會使內建伺服器一直處于繁忙狀态，而你不得不等待他人的build過了以後，才能看到自己送出的結果。
B 要等很長時間才能知道我的送出是否通過了
C 如果build失敗了，要花很長時間才能知道是否和自己的修改相關
D 即使送出了fix，也不知道自己的送出是否真的fix了build.
E build常常處于失敗狀态。
2. 做為測試人員
F 測試人員不知道在哪裡拿build來進行測試.
G 釋出管理者不知道目前各種各樣的測試部署環境中，到底部署了哪個版本，包括哪些新功能或修改的bug.
H 不确定同一個build中，是否所有元件的版本都是正确的
3. 做為項目經理
I 不确定各個測試部署環境中的配置是否都與其上運作的build相一緻
J 不确定測試人員測試的是否在正确的運作環境上運作了正确的版本。
4. 其他方面的問題
所有的安裝都是手工操作.
以上這些問題會給你的釋出管理帶來無限的問題和風險。 那麼，是否因為這種“持續鬧心”就放棄持續內建呢？回答當然是否定的。Do it more if it hurts you. 不要因問題的暴露而放棄，相反，應該歡呼。因為這反映了釋出過程中的問題與風險，是時候解決它們了。
三、如何解決大規模項目中的持續內建問題
由于大項目本身的複雜性，其解決方案也不能一概而論。下面以某大型項目為例，介紹其中的幾個解決方法。
1、項目基本資訊描述
該項目最初就試圖建立一個好的持續內建環境和基礎。雖然能夠得到工作的軟體，但是由于隊伍不斷壯大，而且環境也在不斷變化，持續內建達不到預期目标。
項目背景:
項目是一個具有可配置性的Web 門戶産品，面向不同行業的市場，可自己定制門戶。該項目有一個遺留的代碼庫，而且可以肯定的說，在今後的一年半之内是無法擺脫這個遺留代碼庫的。而且，很多緊耦合的、不必要的臃腫代碼，同時根本不存在有價值的測試代碼。現在我們在逐漸地重寫代碼，但還是不能删除它們，因為某些網站還要依賴于舊代碼。事實上，這是一個.NET平台上基于SOA的網站。
開發團隊情況：
團隊是一個靈活分布開發團隊（三地協作，均有開發人員，且有時差）。整個團隊有150多人，分成十幾個團隊，每個團隊都有一個完成的結構（BA/DEV/QA），其中有一個是項目持續內建團隊（最初大約有五六個人，工作負荷很大），最後隻要兩個人就足夠了。使用SVN做版本管理工具，在Windows2003上使用NAT, MSbuild和batch腳本進行建構管理，最初使用CC.NET做為持續內建伺服器。
持續內建環境：
上面所述的持續內建問題在項目一開始就出現了，因為該項目有一個龐大的遺留代碼庫，而且使用的基本持續內建方式（build->test->package）而且測試人員手工部署進行各類測試。
其初始的持續內建環境如下所示：
第一步目标：盡量減少團隊之間影響
方法：先化整為零，再化零為整 ————根據團隊劃分代碼（或者根據代碼劃分團隊）。
手段：DVCS＋私有持續內建伺服器＋全局持續內建伺服器
每個團隊都使用GIT做為中間源代碼管理工具。這樣，團隊人員可以先送出到GIT。每個團隊有自己的持續內建環境。一但建構成功，觸發将代碼送出到中心的源代碼庫，并觸發中心源代碼的持續內建。有一個專職團隊負責全局持續內建的結果跟蹤。
益處：1. 每個團隊都可以天天送出代碼 （如果這些代碼沒有讓自己的建構失敗，就說明至少能夠通過初步檢驗）。
2. 任何一個團隊的建構壞了，并不影響整個項目，而隻是一個團隊。
3. 有一個專職團隊負責全局，不用每個團隊都停下來。
4. 如果全局持續內建失敗了，不用所有的團隊停下。
第二步目标：提高回報速度
方法：化整為零，再化零為整————測試分組運作。
手段：并行化與中心倉庫（Cruise的并行化與中心倉庫）
由于功能多且複雜，測試較多，運作很長。利用Cruise的并行化特點，每個團隊将測試分成28組。一旦送出後，Cruise會将其放在28台機器上并行運作。運作後，将所有測試輸出和結果上傳到同一處（Cruise Server的中心倉庫）。
益處：1. 回報時間大幅度縮短（原來30分鐘以上，現在20分鐘之内）。
2. 易擴充：如果因測試增多而導緻回報周期長，可通過增加更多的機器解決。
3. 易維護：對于測試分組和建構機器的增減來說，在Cruise中都非常容易，隻要在同一處修改配置即可。
4. 易追蹤和Debug：所有的資訊（包括artifacts）都放在同一處，能過Web通路。
5. Single view (在同一個Web管理頁面上，可以監控所有團隊的建構狀态)。
第三步目标：減少手工操作
方法：一鍵釋出————自動化部署
手段：Cruise (Cruise的dependency + Story Tracker plugin + audit)
由于有很多個團隊，每個團隊都有多個測試環境。如果全部使用手工部署分花費很多時間。是以，每個團隊建立三個建構管道，其目标分别為：(1)得到測試過的 installer；(2)部署到測試環境中；(3)将通過測試的installer部署到示範環境中。前一個建構成功後，就可以觸發下一個（自動或手動）。
益處：1. QA可以清晰識别需要測試哪個安裝包，該安裝包中含有哪些功能
2. QA自己可能很容易地部署測試環境。
3. 易于追蹤功能的曆史版本(在同一個pipeline中，所有的stage同一版本.而且在使用Pipeline dependency時，版本資訊會向下遊傳遞)。
4. 易于掌握對各種部署環境的管理。
使用上述手段後，該項目的持續內建已入佳境。目前可以做到：
- 所有的建構和部署都是自動化的；
- 開發人員最多在20分鐘内就會得到回報。
- 對于每個環境來說，可以做到每天部署四次。
- 部署無差錯：因為是自動化過程，每次的執行步驟都一樣。
- 機器資源複用：Cruise自動向165台機器上分發工作進行建構和部署。
- Single dashboard view of everything!
- 開發人員非常高興：他們可以多次送出而不影響他人。
- 測試人員非常高興：他們可以很快地得到好的installer，通過自己點一下按鈕就完成部署工作。
- 管理人員非常高興：他們可以馬上了解目前的項目狀态（哪些版本在測試中，那些版本已經示範了）。
- 很容易了解每個版本裡包括哪些功能和修複了哪些缺陷。
最終的持續內建環境中共計有260個建構和部署機器，每六周一個release，每個release需要生成15個獨立的安裝包.