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

　　因?yàn)槭窃谡搲�上，互相之間的交流容易造成理解上的偏差，我便闡述了一下我的理解：

　　嗯……也就是說分一個(gè)fastbuild和一個(gè)slowbuild然后有專人蘭注slowbuild。

　　那我的理解，這個(gè)fastbuild應(yīng)該是反映了后臺的健康和前臺于后臺的基本集成的健康。主要用來完成保障集成的角色。

　　而slowbuild則是反映了從用戶接口來看的軟件的健康狀況，定期回歸，防止發(fā)生過的錯(cuò)誤再次發(fā)生。

　　這樣邏輯上看著很清晰，但是兩者之間的同步……會不會有什么問題呢?

　　JeffXiong認(rèn)可了我的理覽，并提出了更進(jìn)一步的解釋和建議：

　　slowbuild實(shí)際上是運(yùn)行完整的回歸測試套件。當(dāng)然理想的情況是slowbuild基本上不出錯(cuò)，因?yàn)殄逸嬘脝卧獪y試都覆蓋到了，功能測試只是在描述表現(xiàn)形式。那么因?yàn)閟lowbuild基本上不出錯(cuò)，就沒有價(jià)值每次都去運(yùn)行它，讓它在后臺慢慢的跑著，過一段時(shí)間(半天或者兩小時(shí))去關(guān)注它一下，沒問題就好，偶爾出了問題就馬上解決并且加上對應(yīng)的單元測試。這樣你既節(jié)約了時(shí)間又不會嚴(yán)重降低對質(zhì)量的保障力度。

　　實(shí)際上的情況可能比較難這樣理想，但是和所有好的環(huán)境一樣，這個(gè)環(huán)境不是說一下子規(guī)劃好就萬亊大吉的。你可能大概的分一分，然后不斷的維護(hù)，在兩組build之間交換測試案例，一些覆蓋到大量功能的、經(jīng)常出錯(cuò)的案例也許要換到fastbuild的冒煙套件里面，一些看起來永遠(yuǎn)不會出錯(cuò)的案例也許可以換到slowbuild去。一直琢磨這個(gè)亊，它才會變得越來越好。