信息系統(tǒng)項(xiàng)目管理：跌撞的持續(xù)系統(tǒng)集成之路(2)

　　最早，我們發(fā)覺，由開發(fā)人員重構(gòu)造成的腳本失敗占大多數(shù)，而測(cè)試人員每次拿到的上一個(gè)版本是沒有錯(cuò)誤的。所以會(huì)出現(xiàn)自動(dòng)化腳本本地跑得過，服務(wù)器上跑不開的情況發(fā)生。二是我們修改了發(fā)布的邏輯，在后臺(tái)單元測(cè)試通過、flash編譯完成的情況下打的那個(gè)war包，復(fù)制一份，放到某待定目錄指定為currentbuild。供測(cè)試人員寫測(cè)腳本使用。

　　過程改進(jìn)之后，測(cè)試人員可以快速的修正腳本了，雖然對(duì)于開發(fā)人員重構(gòu)造成測(cè)試人員工作的返工無疑是一種浪費(fèi)，但是畢竟自動(dòng)化的測(cè)試省了回歸測(cè)試的不少時(shí)間，還是可以接受。

　　腳本的修正速度解決之后，工作似乎有了些起色，但很快，問題的本質(zhì)就暴露了出來build的時(shí)間太長(zhǎng)了，修得速度還是跟不上問題產(chǎn)生的速度。尤其是中間缺少當(dāng)build失敗時(shí)強(qiáng)制阻止代碼提交的環(huán)節(jié)。這之后依然是周一和周五兩頭綠，中間都是紅的。于是，我們覺得問題還是出在build速度上。我們?nèi)斯さ膶⒐δ軠y(cè)試腳本分到四個(gè)suite里去，然后以多線程的方式進(jìn)行。速度被提高了4倍。于是又消停了兩天。

　　好景不長(zhǎng)，多線程的測(cè)試似乎不太穩(wěn)定。很多本地可以跑通的測(cè)試用例，到了服務(wù)器上就失敗。險(xiǎn)些一個(gè)禮拜都沒有build出一個(gè)版本。最后不得不改回單線程。這時(shí)，build一次已經(jīng)占到了100分鐘。第一期的產(chǎn)品Backlog還沒有完成1/3。

　　持續(xù)集成走到這里已經(jīng)進(jìn)入一個(gè)困境，有必要做一些更深一步的改進(jìn)。經(jīng)過多次討論，歸納出了幾套方案：

　　分冒煙測(cè)試和all test兩套測(cè)試用例集是我們當(dāng)中呼聲最高的一種方案，當(dāng)我的代碼提交之后在跑完所有單元測(cè)試和基本的冒煙測(cè)試之后就發(fā)布beta版，由測(cè)試人員接到beta版，進(jìn)行更細(xì)致的自動(dòng)化測(cè)試并帶一些人肉測(cè)試。但是反對(duì)的聲音認(rèn)為，不跑完全部的測(cè)試用例就失去了持續(xù)集成的意義。而且會(huì)更降低開發(fā)人員修正Bug的積極性。于是作為修正，支持的聲音則提出，在Check-InGate處把關(guān)，恢復(fù)每個(gè)人提交代碼之前跑測(cè)試用例的實(shí)踐。可這明顯會(huì)給開發(fā)人員帶來更大的工作負(fù)擔(dān)，估計(jì)以此時(shí)的進(jìn)度壓力，開發(fā)人員的安全感肯定會(huì)大幅下降。很可能會(huì)推行不下去。