持續集成之戲說Check-in Dance(2)

　　Joe解釋到：“主要是因為我們每個人的本地環境都不完全相同，很可能出現‘它在我的機器沒有問題呀’的這個現象，所以還是要在獨立的持續集成服務器上再運行一次。”

　　因此，大家就這么決定了。

　　四、兩次本地構建的目的

　　四周后的一天，Joe花了很長時間完成了某個新功能后，打算提交了。于是他把分支當前的代碼與其本地代碼進行了一次合并。然后運行了本地測試，但測試失敗了。他用了很長時間來定位該問題是在他自己修改的功能里，還是在被合入的代碼中。這讓他對提交流程進行了反思。

　　“要是在合入他人代碼之前，能夠先運行一次本地測試，驗證一下我的代碼沒問題就好了，反正本地測試所花的時間也不長。”

　　于是，他把這個想法告訴了其他人，最后大部分人都同意這么做。于是，其提交流程就變成了這樣：?

　　每個人在開發新代碼之前，只能從持續集成完全成功的那個最新版本檢出代碼;

　　開發新功能或修改bug;

　　運行本地測試，如果有失敗就立即修復，直至測試成本;

　　提交前將主分支上的代碼再次取到本地合并;

　　運行本地測試，確保測試可以通過;

　　提交代碼到主分支，由持續集成服務器再次運行測試。

　　如果測試通過，轉到步驟(1);

　　如果測試沒有通過，轉到步驟(2)。

　　這個過程就被稱為“Check-in Dance”。

　　Alice還說道：“我們在從主分支上檢出代碼時，一定是那個通過持續集成驗證的最新版本。這樣可以避免檢出的代碼就是有問題的，而影響自己本地的代碼。”整個過程如圖4所示。

　　五、持續集成令牌

　　過了幾天，有人把大家叫到了一起，這次是Alice。她說：

　　“我今天遇到一個問題。我提交代碼之后，正等著持續集成服務器返回結果呢，Bob就提交代碼了。幸好我提交的代碼通過了測試，否則的話，我就要在Bob的代碼之上修復啦。所以，我建議我們需要設立一個提交令牌，只有拿到這個提交令牌的人才能提交。也就是說，當一個人做完本地測試之后，去拿這個令牌。拿到之后，再進行代碼合并、本地測試和提交。提交以后當持續集成服務器返回成功通過的結果時，才能交還令牌。這樣就不會出現我和Bob這種情況了。”

　　可Bob并不同意這樣的做法，“這次沒有出什么問題，為什么還要這么做呢?”

　　此時，Joe把話接了過來，說道：“Alice的這個建議很好，我已經遇上過一次這樣的事情了，那次測試失敗以后，我花了很長時間才發現問題并不在我的提交中，而是在Mary的提交中。我把它修復后，又做了一次提交。”由于大多數人都同意這么做，因此團隊決定試一試。因為目前測試運行時間很短，所以提交和集成工作沒有遇到什么瓶頸。提交流程如圖5所示。

　　似乎事情到這里就結束了。然而，這個游戲被某投資公司看中，決定做更大的投入，招更多的開發人員，讓它成為一個開放游戲平臺。那么，接下來Joe與他的朋友們還會遇到哪些問題呢?

原文轉自：http://www.kjueaiud.com