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

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

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

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

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

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