持續集成之“測試三角形與分段構建策略原則”(2)

　　“不對，這里有問題!持續集成強調盡早反饋。如果把測試分成兩個階段了，那反饋周期不是加長了 嗎?”Bob反駁道。

　　Joe 點點頭，說道：“你說的沒有錯。但是，根據我們現有的軟硬件資源條件，我們目前還無法通過增加資源的方式來縮短所有測試運行的時間。所以我們必須在質量與速度之前做出平衡。這也是我為什么要把那些不易出錯的自動化測試集合放在第二階段構建的原因，這樣可以降低但不能完全解除第二階段構建失敗的風險。所以， 這也要求我們大家當第二階段構建失敗時，也要找人盡快把它解決，并且把相關的測試再次放回提交測試階段中運行，或者在提交測試階段加入新的測試來補充。”

　　Alice此時插話，問道：“既然第二階段構建不常失敗，為什么我們不定時運行它，比如每天晚上運行一次呢?這樣不是更節省資源嗎?另外，如果第二階段構建運行得慢，那它不是一直都落后嗎?”

　　“因為每次提交階段構建成功以后就觸發第二階段構建，這樣無論如何都比每天晚上運行一次的更多的反饋。因為每天晚上運行一次的話，如果出了問題，我們只能在第二天早上才能發現。對于你的第二個問題，我畫一張圖來解釋。”Joe找了一張大白紙，在上面開始畫了起來。

　　一會兒功夫，幾個示意圖就畫好了?？吹竭@幾個示意圖以后，大家恍然大悟。如圖5所示。從圖中我們可以看到：

　　當版本123的第二階段構建被觸發并正在運行，Alice又提交了一次，觸發了版本124的提交構建;

　　當版本124的提交構建完成之后，由于版本123的第二階段構建仍在運行，所以不再觸發第二階段構建;

　　當版本125的提交構建完成時，版本123的第二階段構建仍舊在運行，所以也不觸發第二階段構建;

　　當版本126提交構建正在運行時，版本123的第二階段構建剛完成，此時由于版本125的提交階段構建是一個最近 成功完成的提交構建，所以持續集成服務器就會啟動該版本的第二階段構建，而忽略版本124的提交構建。

　　“那根據我們持續集成紀律，誰的提交讓構建失敗，就由誰來修復。如果版本125的第二階段構建失敗了，就包括版本124和125兩次提交的變更，由誰來修復呢?”Bob接著問道。

　　“這個好辦，由這兩個提交人一起負責修復。如果想確切找到誰的提交有問題，還可以手動觸發版本124的第二次構建。假如構建成功，說明版本125有問題，假如構建失敗，說明問題在版本124就引入了。”Alice搶著說道。

　　討論到這里，團隊成員都達成了共識：(1) 開始加強單元測試的力度;(2) 在反饋速度和反饋質量之間做出折衷，使用二級構建構建的方式。

　　整個產品的開發非常順利，馬上就要進行版本發布了。團隊還會遇到什么問題呢?他們是如何解決的呢?請聽下回分解。

原文轉自：http://kb.cnblogs.com/page/91338/