[TOC] # 簡介 持續集成（CONTINUOUS INTEGRATION）  <br> 在持續集成環境中，開發人員將會頻繁的提交代碼到主干。這些新提交在最終合并到主線之前，都需要通過編譯和自動化測試流進行驗證。這樣做是基于之前持續集成過程中很重視自動化測試驗證結果，以保障所有的提交在合并主線之后的質量問題，對可能出現的一些問題進行預警。 <br> <br> # 需要具備哪些條件 * 你的團隊需要為每個新功能，代碼改進，或者問題修復創建自動化測試用例。 * 你需要一個持續集成服務器，它可以監控代碼提交情況，對每個新的提交進行自動化測試。 * 研發團隊需要盡可能快的提交代碼，至少每天一次提交。 <br> <br> # 能獲得什么 * 通過自動化測試可以提早拿到回歸測試的結果，避免將一些問題提交到交付生產中 * 發布編譯將會更加容易，因為合并之初已經將所有問題都規避了 * 減少工作問題切換，研發可以很快獲得構建失敗的消息，在開始下一個任務之前就可以很快解決。 * 測試成本大幅降低-你的CI服務器可以在幾秒鐘之內運行上百條測試。 * 你的QA團隊花費在測試上面的時間會大幅縮短，將會更加側重于質量文化的提升上面。 <br> <br> # 流程 根據持續集成的設計，代碼從提交到生產，整個過程有以下幾步。 <br> ## 提交 流程的第一步，是開發者向代碼倉庫提交代碼。所有后面的步驟都始于本地代碼的一次提交（commit）。 <br> ## 測試（第一輪） 代碼倉庫對commit操作配置了鉤子（hook），只要提交代碼或者合并進主干，就會跑自動化測試。 測試有好幾種。 * 單元測試：范圍非常小，驗證每個獨立方法級別的操作。 * 集成測試：保證模塊間運行正常，包括多個模塊、多個服務。 * 驗收測試：與集成測試類似，但是僅關注業務case，而不是模塊內部本身。 * UI測試：從用戶的角度保證呈現正確運行。  第一輪至少要跑單元測試。 <br> ## 構建 通過第一輪測試，代碼就可以合并進主干，就算可以交付了。 交付后，就先進行構建（build），再進入第二輪測試。所謂構建，指的是將源碼轉換為可以運行的實際代碼，比如安裝依賴，配置各種資源（樣式表、JS腳本、圖片）等等。 常用的構建工具如下。 > * [Jenkins](http://jenkins-ci.org/) > * [Travis](https://travis-ci.com/) > * [Codeship](https://www.codeship.io/) > * [Strider](http://stridercd.com/) Jenkins和Strider是開源軟件，Travis和Codeship對于開源項目可以免費使用。它們都會將構建和測試，在一次運行中執行完成。 <br> ## 測試（第二輪） 構建完成，就要進行第二輪測試。如果第一輪已經涵蓋了所有測試內容，第二輪可以省略，當然，這時構建步驟也要移到第一輪測試前面。 第二輪是全面測試，單元測試和集成測試都會跑，有條件的話，也要做端對端測試。所有測試以自動化為主，少數無法自動化的測試用例，就要人工跑。 需要強調的是，新版本的每一個更新點都必須測試到。如果測試的覆蓋率不高，進入后面的部署階段后，很可能會出現嚴重的問題。 <br> ## 部署 通過了第二輪測試，當前代碼就是一個可以直接部署的版本（artifact）。將這個版本的所有文件打包（`tar filename.tar *`）存檔，發到生產服務器。 生產服務器將打包文件，解包成本地的一個目錄，再將運行路徑的符號鏈接（symlink）指向這個目錄，然后重新啟動應用。這方面的部署工具有[Ansible](http://www.ansible.com/)，[Chef](https://www.chef.io/chef/)，[Puppet](https://puppetlabs.com/)等。 <br> ## 回滾 一旦當前版本發生問題，就要回滾到上一個版本的構建結果。最簡單的做法就是修改一下符號鏈接，指向上一個版本的目錄。 <br>