跌撞撞的持續集成之路(2)

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

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

　　Jeff Xiong覺得可以將測試分級，并將build分為兩個環節，一個跑基本的用例，一個跑全部的用例。這跟我們的第一套方案的思路吻合。但是這種行為是不是失去了持續集成的意義呢?他也不是很確定，他說：

　　我也不確定……不過，不全面的持續集成至少比不能用的持續集成要好。哪怕一個quick build(只?)能抓到80%(70%?60%?50%?)的defect，如果它只要很少的時間就能跑一遍，似乎值得這樣做。

　　不過同時就需要(可能是專門的)人來關注slow build的健康狀況，不然broken functional tests可能被忽視并累積。

　　因為是在論壇上，互相之間的交流容易造成理解上的偏差，我便闡述了一下我的理解：

　　嗯。。。也就是說分一個fast build和一個slow build然后有專人關注slow build。

　　那我的理解，這個fast build應該是反映了后臺的健康和前臺與后臺的基本集成的健康。主要用來完成保障集成的角色。

　　而slow build則是反映了從用戶接口來看的軟件的健康狀況，定期回歸，防止發生過的錯誤再次發生。

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

　　Jeff Xiong認可了我的理解，并提出了更進一步的解釋和建議：

　　slow build實際上是運行完整的回歸測試套件。當然理想的情況是slow build基本上不出錯，因為*邏輯*用單元測試都覆蓋到了，功能測試只是在描述*表現形式*。那么因為slow build基本上不出錯，就沒有價值每次都去運行它，讓它在后臺慢慢的跑著，過一段時間(半天或者兩小時)去關注它一下，沒問題就好，偶爾出了問題就馬上解決并且加上對應的單元測試。這樣你既節約了時間又不會嚴重降低對質量的保障力度。

　　實際上的情況可能比較難這樣理想，但是和所有好的環境一樣，這個環境不是說一下子規劃好就萬事大吉的。你可能大概的分一分，然后不斷的維護，在兩組build之間交換測試案例，一些覆蓋到大量功能的、經常出錯的案例也許要換到fast build的冒煙套件里面，一些看起來永遠不會出錯的案例也許可以換到slow build去。一直琢磨這個事，它才會變得越來越好。

　　(題外話：最近我覺得稍微大一點的項目應該有比較專注的build master，developers往往并不是特別認真的考慮build和CI的持續改進。)

　　而胡凱則提出了一些基于CC采用分布式的解決思路：

　　CruiseControl是支持一個叫做Distribute的Contrib，它的Idea是：因為CruisControl支持叫做Composite的build方式，那么你可以起多個build server一起來build同一個項目，當且僅當所有的子build通過，整個build才算成功。

　　對于每個build server，你是在單線程測試，對于整個項目，你卻是并發測試，因為有多個server同時在跑測試。

　　但是他也說到CC畢竟是開源的東西，配置起來十分麻煩，于是最后也提出了采用Cruise的方案^_^:

　　或者你也可以嘗試一下ThoughtWorks新發布的Cruise, 基本的理念很相似， 都是把測試分布到不同的機器上執行。

　　在試用期內可以同時跑6個Agent.你可以在每個Agent上執行不同的Target比如

　　Agent1 : ant ft.suite.1

　　Agent2 : ant ft.suite.2

　　Agent3 : ant ft.suite.3

　　你可以拿來玩兒下，根Open Source的那個比起來，應該容易設置很多。

　　缺點是：

　　你必須使用 hg或者svn 作為 SCM

　　試用期過后，你只有2個免費的Agent

　　另外，糖醋鼻子還提到了分支式開發，大家圍繞這個還展開了激烈的討論，不過我考慮到分支式開發對我們的利可能要遠小于弊，最終還是放棄了這個方案。

　　在吸取了兩方面的建議之后，經過一番思考，決定開始兩方面的準備，一方面，對測試用例的分級方面做了一些工作，重構了一部分用例的結構。另一方面我去調研分布式構建的實現手法。CC的配置果然非常麻煩，調研期間發現了有RemoteAnt這個東西，試了一下基本滿足我們的需求，考慮到一個Agent不用做的太過重型，于是就采用了這個方法。在分布式的技術調研已經完成的情況下，測試分級要不要做成了一個問題，但考慮到目前需求只作了1/3，如果這個都抗不住要分級的話，后面的工作就沒法做了，所以分級的事情，雖然做了，但是也暫緩實行。

　　現在實踐已經采用，會不會產生新的問題呢?前文說過“興一利必也生一弊”，這個事情是肯定的。那么問題就來了，既然弊端肯定會滋生，我們怎么知道作出的決策是正確的呢?

　　其實，倒回去看這一路走來的過程，除了一個可以運行的過程以外，還有一個很重要的收獲，那就是：如何進行決策。而所謂決策，并不是在黑白分明的事情之間做出選擇，而是在都有理的事情中做出選擇。就像我們都知道做軟件設計的時候，設計是沒有好壞之分的，只有適不適應你的具體情況之別。所以當我們面臨幾套解決方案的時候，就好象面對幾套設計方案一樣，真的是很難選擇。如何做?各自就有各自的思路了。像我們就吸收了敏捷開發的思想中所強調得不做過度設計。選擇立桿見影的改進去做。同時，像前文所說，抱著擁抱變化的態度，相信興一利必生一弊并不是壞事。相反，他可以從一定程度上，帶領我們找到真正的問題。

原文轉自：http://www.anti-gravitydesign.com