再釋“持續整合，應該自動化什嗎？”

持續整合是敏捷最佳實務之一，但並不是只有使用敏捷方法的團隊才能夠採納。但如果你能夠採納敏捷方法，那麼它會發揮更大的作用。

“什麼是持續整合”在前面的文章中已談過了，這裡只把其中的一部分：持續整合的六個基本自動化再細說一下。這六個基本自動化是：自動運行測試、自動產生可部署的二進位檔案，把它部署到類似生產環境中，自動標識你的代碼基準，自動運行迴歸測試以及自動產生度量。

一、運行測試
　　這本來是不必說的事情，但還是有很多項目，其持續整合過程只是去編譯一下代碼，就不做別的了。可在持續整合過程中的綠色應該表示的是可以工作的軟體 – 可沒有自動化的測試，你哪會有信心呢？一套好的測試應該儘可能多地覆蓋到所有代碼，而且運行也要儘可能地快（也就是說，你的最主要的那個構建應該不超過10分鐘），同時不要依靠於其它基礎環境（如資料庫或訊息通道）。
 
二、產生可部署的二進位代碼
　　 它可以是一個能部署在Web應用伺服器上的jar包，也可能是一個MSI安裝檔案。無論你用哪種方法安裝你的軟體，持續整合過程都要做打包工作並最終產生這個東西。這樣，測試人員就可以從持續整合工具的頁面上直接下截這個安裝包來測試了，這樣就減少了從檢入代碼到知道代碼可以工作之間的反饋時間。持續構建所產生可部署的二進位代碼也意味著它是被不斷測試的，以免最終產品上線時遇到麻煩。

三、部署你的產品到與生產環境類似的環境中
　　 讓你的產品能在非開發環境中運行通常是項目比較困難的問題，特別是產品需要部署在非常複雜的環境時。而使你的部署過程自動化並把測試這一過程也作為持續整合的一部分，會緩解這些問題。而且，這也 意味著你的測試人員更易於在真實環境中測試你的軟體——這樣，對你的軟體真的可以使用更有信心了。

四、標識你的代碼基準
　　SVN這類版本控制工具是支援原子提交的，它們可以將開發人員的每次檢入都用版本號碼打上標識，但象CVS這類版本控制工具就不支援原子提交。另外，你的源檔案也可能分散在不同的程式碼程式庫中。所以一定要自己在持續整合過程中把每一次構建都打上標識。這樣，一旦在測試中發現問題，你就可以追溯到正確的版本來修正它。

五、運行迴歸測試
　　如果你有已耗用時間比較長的接受性測試或迴歸測試，最好也把它們自動化起來，並進行周期性的運行。由於它們已耗用時間會比較長，所以可以不放在主構建中，否則就會影響主構建的反饋速度。但是，至少每天晚上你都要運行一次，如果可能的話，間隔時間可以再短一點。這不但可能給你額外的信心，而且還可能確保你一直在更新你的迴歸測試或接受性測試。當代碼發生變化後，這種接受性測試很容易失敗，因為這些代碼不再反映需求了。

六、產生度量資料
　　 你要小心處理“度量”這件事，因為它對你的開發人員有很大影響。度量代碼的測試覆蓋率就是常持續整合共同使用的常見度量方法——但用它也很容易導致開發人員寫出無用卻可以提高覆蓋率的代碼。可是，如果你的團隊都能接受這些的話，那麼使用代碼覆蓋統計、代碼式樣檢查、依賴分析等方法可以促使開發人員不斷地改進代碼品質。

當然，還可以做其他自動化工作，如產生文檔、產生資料庫指令碼等等。但是，如果最基本的自動化都做不到，那其他事情就不用做了。

原文見連結