軟件測試中大規模項目團隊持續集成實踐之一二

軟件測試中大規模項目團隊持續集成實踐之一二

一、持續集成基礎

在典型的軟件項目中，集成階段一般都是在最后，因此也是出現問題最多，而且最有可能導致不能按時交付。而持續集成（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 門戶產品，面向不同行業的市場，可自己定制門戶。該項目有一個遺留的代碼庫，而且可以肯定的說，在今后的一年半之內是無法擺脫這個遺留代碼庫的。而且，很多緊耦合的、不必要的臃腫代碼，同時根本不存在有價值的測試代碼�，F在我們在逐步地重寫代碼，但還是不能刪除它們，因為某些網站還要依賴于舊代碼。事實上，這是一個.NET平臺上基于SOA的網站。

開發團隊情況：

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

持續集成環境：

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

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

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

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

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

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

益處：

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

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

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

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

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

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

手段：并行化與中心倉庫（Cruise的并行化與中心倉庫）