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

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

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

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

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

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

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

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

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

　　試用期過后，你只有2個(gè)免費(fèi)的Agent另外，糖醋鼻子還提到了分支式開發(fā)，大家圍繞這個(gè)還展開了激烈的討論，不過我考慮到分支式開發(fā)對(duì)我們的利可能要遠(yuǎn)小于弊，最終還是放棄了這個(gè)方案。