持續集成－Continuous integration,簡稱CI。
一、介紹
持續集成，就是頻繁的將代碼集成到主幹（trunk）上。
有兩個優點：
（1）快速發現問題：每次完成一點更新，就會集成到主幹上，可以快速發現bug，定位問題也比較容易
（2）防止分支branch大幅偏離主幹：若不經常集成，主幹又在不斷更新，會導致以後集成的難度變大，甚至難以集成。
持續集成的目的，是讓產品可以快速迭代，同時還能保持高質量。核心措施是，代碼集成到主幹之前，必需通過自動化測試。有一個測試用例失敗，就不能集成。
持續集成不能完全消除bug，而是讓它們非常容易發現和改正。與持續集成相關的，還有持續交付和持續部署。
二、持續交付
持續交付－Continuous delivery，指頻繁地將軟件的新版本，交付給質量團隊或者用戶，以供評審。若評審通過，則代碼進入生產階段。
持續交付可以看作持續集成的下一步，它強調不管怎麼更新，軟件時隨時隨地可以交付的。
三、持續部署
持續部署－Continuous deployment是持續交付的下一步，指將代碼通過評審後，自動部署到生產環境。
持續部署的目標是，代碼在任何時候都是可以部署的，可以進入生產階段。
持續部署的前提是能自動化完成測試、構建、部署等步驟。他與持續交付的區別如下：
continuous delivery ==code done--(auto)--unit tests--(auto)--integrate--(auto)--acceptance test--(manual)--deploy to production
continuous deployment==code done--(auto)--unit tests--(auto)--integrate--(auto)--acceptance test--(auto)--deploy to production
四、流程
根據持續集成的設計，代碼從提交到生產，整個過程有以下幾步：
4.1 提交
流程的第一步，是開發者向代碼倉庫提交代碼。所有後面的步驟都始於本地代碼的一次提交（commit）.
4.2 測試（第一輪）
代碼倉庫對commit操作配置了鉤子（hook），只要提交代碼或者合併進主幹，就會跑自動化測試。
測試有好幾種：
單元測試：針對函數或模塊的測試
集成測試：針對整體產品的某個功能的測試，又稱功能測試
端對端測試：從用戶界面直達數據庫的全鏈路測試
第一輪至少跑單元測試。
4.3 構建
通過第一輪測試，代碼就可以合併進主幹，就算可以交付了。
交付後，就先進行構建（build），再進入第二輪測試。所謂構建，指的是將源碼轉換爲可以運行的實際代碼，比如安裝依賴，配置各種資源（樣式表、JS腳本、圖片）等等。
常用的構建工具如下：Jenkins、travis、codeship、strider
4.4 測試（第二輪）
構建完成，就要進行第二輪測試。若第一輪已經涵蓋了所有測試內容，第二輪可以省略，當然，這時構建步驟也要移到第一輪測試前面。
第二輪是全面測試，單元測試和集成測試都會跑，可以的話，也要做端對端測試。所有測試以自動化爲主，少數無法自動化的case，就要人工跑。
需強調的是，新版本的每一個更新點都必須測試到。如果覆蓋率不高，進入後面的部署階段後，很可能會出現嚴重的問題。
4.5 部署
通過了第二輪的測試，當前代碼就是一個可以直接部署的版本(artifact) ，將這個版本的所有文件打包存檔，發到生產服務器。
生產服務器將打包的文件，解包成本地的一個目錄，再將運行路徑的符號鏈接（symlink）指向這個目錄，然後重新啓動應用。這方面的部署工具有Ansible, Chef, Puppet等。
4.6 回滾
一旦當前版本發生問題，就要回滾到上一個版本的構建結果，最簡單的做法就是修改一下符號鏈接，指向上一個版本的目錄。