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

　　另一個方案是從細節(jié)處調(diào)優(yōu)，把WEB應(yīng)用部署到另外一臺機器上去，或許就會穩(wěn)定一些了。但是反對的聲音認為，以測試用例的這個增長速度，他早晚會不穩(wěn)定的，而且可能撐不過兩周。作為修正，想考慮分布式，但是我們所有人的知識儲備中，并沒有一個人清楚CC有沒有分布式能力。所以想的是購買Cruise，但是價格的障礙就擺在眼前了，在項目前景還不是很明郎的情況下，估計很難申請到資金，但也不是不可能，只要我們敢于冒這個風(fēng)險。

　　第三，便是更為高級的分支式開發(fā)，將版本庫劃分一下分支，以分支來搭配持續(xù)集成，以分支合并來觸發(fā)自動構(gòu)建。這樣做，開發(fā)的過程就更加有板有眼，粒度可以劃分的更細�？墒欠种У膭澐�，一時想不清楚。但是假設(shè)想清楚了，似乎這也使得我們的工作流程更加復(fù)雜了，做如此之大的改變，風(fēng)險有多大?效果有多大?成本有多大?到底是值不值得?一時也想不清楚。

　　方案有了，聽起來都很有道理，也都有問題。該如何做出決策，是個問題。現(xiàn)在大家眾說紛紜，都有理，就變得難以抉擇。而且到現(xiàn)在了是不能隨便嘗試的，這種嘗試也是一種風(fēng)險，一旦出問題造成的成本上升都會加大我們身上的壓力。

　　迷茫之下到AgileChina上跟大家討論了一下。非常高興的收集到了幾方面的建議：

　　JeffXiong覺得可義將測試分級，并將build分為兩個環(huán)節(jié)，一個跑基本的用例，一個跑全部的用例。這跟我們的第一套方案的思路吻合。但是這種行為是不是失去了持續(xù)集成的意義呢?他也不是很確定，他說：我也不確定……不過，不全面的持續(xù)集成至少比不能用的持續(xù)集成要好。哪怕一個quickbuild(只?)能抓到80%(70%?60%?50%?)的defect，如果它只要很少的時間就能跑一遍，似乎值得這樣做。

　　不過同時就需要(可能是與門的)人來關(guān)注slowbuild的健康狀況，不然brokenfunctionaltests可能被忽視并累積。