“持續整合”之一二三

自動化測試是持續整合的前提

毋庸置疑，自動化測試是持續整合的前提。

如果您的項目還沒有單元測試或功能測試代碼，那麼持續整合的意義就不那麼重要了。只有隨著項目的進行，不斷增多的自動化測試，才能突顯持續整合的重大意義。持續整合是代碼健康情況的指標或風向標。通過持續整合，可以儘早發現問題，提醒團隊成員儘早修複問題，得到更健康的代碼。

持續整合有很多實踐，通過實際項目的經曆，總結三個基本實踐：

一、儘早開始

持續整合應該在項目初始階段就給予考慮，並在搭建開發環境的同時建立持續整合環境。而且，你最先check-in的代碼檔案應該包括你的構建指令碼，從而觸發第一次構建，並使這次構建通過。此後，你所需要做的就是不斷增加代碼，改進構建過程。

有人可能會說：“剛開始時，代碼那麼少，大家工作在不同的功能模組上，衝突不多，自己手工運行一下測試不就行了，等以後再建持續整合環境吧。”
其實，很多時候一旦說“等以後”，那就等於說“Never”。就象單元測試一樣，“開始時代碼這麼簡單，不用測試也沒問題；而當認為代碼不那麼簡單需要測試時，就會發現此時單元測試太難了，要重寫好多代碼，還是不寫了吧！”結果可想而知。

所以，持續整合還是在項目最簡單的時候引入為好。

二、儘快運行

持續整合最主要的目的就是得到儘早的反饋。項目開始時，代碼較少，持續整合所用的時間不會太長，只有幾分鐘。對於Team Dev來說，這個時間還可以忍受。可是，隨著程式碼程式庫的不斷增大，功能增多，持續整合所花的時間越來越長，以至於影響Team Dev的生產力。一定要在此之前再去最佳化你的持續整合。因為當你意識到這個問題的時候，它已經產生了負面影響。那麼如何讓持續整合儘快運行呢？

一般來說，有三種途徑可以達到：（一）最佳化代碼，即通過對現有代碼的最佳化使運行更快，如儘可能地減少外部依賴，使用記憶體資料庫代替基於檔案系統的資料庫等；（二）縱向擴充，即通過增強持續整合所需硬體的效能［如記憶體，CPU］等提高運行速度；（三）橫向擴充，即通過將測試分成多個部分，在多個環境下並行運行後匯總結果，以達到節省時間的目的。

三、專人負責

在項目中，要有專門的人員或角色（CI engineer）來負責持續整合的改進。只有某種任務有相應的責任人後，該任務的執行才能得到保障。這一點在較大或較複雜的項目中尤其重要。

因為在項目較小，人員較少的情況下，大家可能會對持續整合的環境都非常瞭解，只要有問題發生，都會找到問題，加以解決。但是，在較大較複雜的項目中，持續整合環境可能會比較複雜，持續整合的伺服器以及構建機在哪裡，有什麼樣的配置，如何管理不可能被所有的項目成員瞭解。此時，就該CI engineer出現了。他的責任就是儘可能地利用資源使持續整合的周期縮短，使反饋更加迅速。

當然，這並不是說，有了CI engineer，持續整合的結果就由他負責。對於持續整合中的失敗，所有團隊成員都有責任有義務去fix，即使自己不能fix，也要找到正確的人去fix。

當然，這並不是持續整合的全部，只是持續整合的基本實踐。只有做到了這三個基本實踐，才能高效地發揮持續整合的作用。