一、概念

持續整合指的是，頻繁地（一天多次）將程式碼整合到主幹。

它的好處主要有兩個。

（1）快速發現錯誤。每完成一點更新，就整合到主幹，可以快速發現錯誤，定位錯誤也比較容易。 
（2）防止分支大幅偏離主幹。如果不是經常整合，主幹又在不斷更新，會導致以後整合的難度變大，甚至難以整合。

持續整合的目的，就是讓產品可以快速迭代，同時還能保持高質量。它的核心措施是，程式碼整合到主幹之前，必須通過自動化測試。只要有一個測試用例失敗，就不能整合。

Martin Fowler說過，”持續整合並不能消除Bug，而是讓它們非常容易發現和改正。”

與持續整合相關的，還有兩個概念，分別是持續交付和持續部署。

二、持續交付

持續交付（Continuous delivery）指的是，頻繁地將軟體的新版本，交付給質量團隊或者使用者，以供評審。如果評審通過，程式碼就進入生產階段。

持續交付可以看作持續整合的下一步。它強調的是，不管怎麼更新，軟體是隨時隨地可以交付的。

三、持續部署

持續部署（continuous deployment）是持續交付的下一步，指的是程式碼通過評審以後，自動部署到生產環境。

持續部署的目標是，程式碼在任何時刻都是可部署的，可以進入生產階段。

持續部署的前提是能自動化完成測試、構建、部署等步驟。它與持續交付的區別，可以參考下圖。 
 
四、流程

根據持續整合的設計，程式碼從提交到生產，整個過程有以下幾步。

4.1 提交

流程的第一步，是開發者向程式碼倉庫提交程式碼。所有後面的步驟都始於原生代碼的一次提交（commit）。

4.2 測試（第一輪）

程式碼倉庫對commit操作配置了鉤子（hook），只要提交程式碼或者合併進主幹，就會跑自動化測試。

測試有好幾種。

單元測試：針對函式或模組的測試 
整合測試：針對整體產品的某個功能的測試，又稱功能測試 
端對端測試：從使用者介面直達資料庫的全鏈路測試

第一輪至少要跑單元測試。

4.3 構建

通過第一輪測試，程式碼就可以合併進主幹，就算可以交付了。

交付後，就先進行構建（build），再進入第二輪測試。所謂構建，指的是將原始碼轉換為可以執行的實際程式碼，比如安裝依賴，配置各種資源（樣式表、JS指令碼、圖片）等等。

常用的構建工具如下。

Jenkins 
Travis 
Codeship 
Strider

Jenkins和Strider是開源軟體，Travis和Codeship對於開源專案可以免費使用。它們都會將構建和測試，在一次執行中執行完成。

4.4 測試（第二輪）

構建完成，就要進行第二輪測試。如果第一輪已經涵蓋了所有測試內容，第二輪可以省略，當然，這時構建步驟也要移到第一輪測試前面。

第二輪是全面測試，單元測試和整合測試都會跑，有條件的話，也要做端對端測試。所有測試以自動化為主，少數無法自動化的測試用例，就要人工跑。

需要強調的是，新版本的每一個更新點都必須測試到。如果測試的覆蓋率不高，進入後面的部署階段後，很可能會出現嚴重的問題。

4.5 部署

通過了第二輪測試，當前程式碼就是一個可以直接部署的版本（artifact）。將這個版本的所有檔案打包（ tar filename.tar * ）存檔，發到生產伺服器。

生產伺服器將打包檔案，解包成本地的一個目錄，再將執行路徑的符號連結（symlink）指向這個目錄，然後重新啟動應用。這方面的部署工具有Ansible，Chef，Puppet等。

4.6 回滾

一旦當前版本發生問題，就要回滾到上一個版本的構建結果。最簡單的做法就是修改一下符號連結，指向上一個版本的目錄。

五、參考連結

Gergely Nemeth, Continuous Deployment of Node.js Applications 
Codeship, Continuous Integration Essentials