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

　　那個(gè)時(shí)候，build一次大概是15分鐘，因?yàn)镃heck In Gate環(huán)節(jié)是按照標(biāo)準(zhǔn)流程走的，所以build出錯(cuò)的幾率也小。CC大多數(shù)時(shí)候是綠的。哪怕偶爾出問題紅了，也很快被修正了。

　　隨著項(xiàng)目的開發(fā)，代碼規(guī)模越來越龐大。功能測試越來越慢，比起自動(dòng)執(zhí)行腳本那種速度，開發(fā)人員更樂意手動(dòng)點(diǎn)兩下，加之上面對工作進(jìn)度的壓力。更改了一些工作方式：后臺(tái)的工作方式不變。

　　前臺(tái)，將功能測試腳本的工作交給幾個(gè)測試人員編寫。幾個(gè)測試人員也坐在附近，基本可以看作團(tuán)隊(duì)成員(到后來編制也是我們團(tuán)隊(duì)的成員了)。開發(fā)人員人肉測試一下保證沒有問題了再提交。

　　測試人員寫腳本的流程是拿到上一次build成功的war包，在本地寫腳本，本地測通過了再提交。

　　持續(xù)集成服務(wù)器上功能測試不通過的時(shí)候，由測試人員提交BUG，開發(fā)人員修改。持續(xù)集成的流程依舊。

　　這樣，從后來收集的數(shù)據(jù)看，工作效率是提升了，因?yàn)閰⒄找郧暗慕y(tǒng)計(jì)，開發(fā)人員的工作一下減輕了1/3。以進(jìn)度來衡量的速度自然很輕易就可以讓上級(jí)滿意了。

　　新的解決方案總會(huì)產(chǎn)生新的問題，測試人員在測試方面的專業(yè)性，使得他們寫出來的腳本測的更細(xì)。功能測試的時(shí)間占耗，增長的更快了，短短半個(gè)月，就增長到了1個(gè)小時(shí)。每當(dāng)出現(xiàn)問題，作出反應(yīng)之后，要在1個(gè)多小時(shí)以后才能知道結(jié)果。而且，持續(xù)集成方面并沒有做到，一旦出錯(cuò)，誰也不能提交代碼這么嚴(yán)格。模塊化的設(shè)計(jì)所帶來的假想的安全感和進(jìn)度的壓力，使得開發(fā)人員修正問題的激勵(lì)不高。于是修正問題的速度不如產(chǎn)生問題的速度快。持續(xù)集成服務(wù)器在那兩個(gè)個(gè)禮拜里只有兩頭是綠的，周一早晨和周五下午。