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

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

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

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

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

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