互聯(lián)網(wǎng)軟件的開發(fā)和發(fā)布，已經(jīng)形成了一套標(biāo)準(zhǔn)流程，最重要的組成部分就是持續(xù)集成（Continuous integration，簡稱CI）。

本文簡要介紹持續(xù)集成的概念和做法。

一、概念

持續(xù)集成指的是，頻繁地（一天多次）將代碼集成到主干。

它的好處主要有兩個(gè)。

（1）快速發(fā)現(xiàn)錯(cuò)誤。每完成一點(diǎn)更新，就集成到主干，可以快速發(fā)現(xiàn)錯(cuò)誤，定位錯(cuò)誤也比較容易。

（2）防止分支大幅偏離主干。如果不是經(jīng)常集成，主干又在不斷更新，會(huì)導(dǎo)致以后集成的難度變大，甚至難以集成。

持續(xù)集成的目的，就是讓產(chǎn)品可以快速迭代，同時(shí)還能保持高質(zhì)量。它的核心措施是，代碼集成到主干之前，必須通過自動(dòng)化測(cè)試。只要有一個(gè)測(cè)試用例失敗，就不能集成。

Martin Fowler說過，"持續(xù)集成并不能消除Bug，而是讓它們非常容易發(fā)現(xiàn)和改正。"

與持續(xù)集成相關(guān)的，還有兩個(gè)概念，分別是持續(xù)交付和持續(xù)部署。

二、持續(xù)交付

持續(xù)交付（Continuous delivery）指的是，頻繁地將軟件的新版本，交付給質(zhì)量團(tuán)隊(duì)或者用戶，以供評(píng)審。如果評(píng)審?fù)ㄟ^，代碼就進(jìn)入生產(chǎn)階段。

持續(xù)交付可以看作持續(xù)集成的下一步。它強(qiáng)調(diào)的是，不管怎么更新，軟件是隨時(shí)隨地可以交付的。

三、持續(xù)部署

持續(xù)部署（continuous deployment）是持續(xù)交付的下一步，指的是代碼通過評(píng)審以后，自動(dòng)部署到生產(chǎn)環(huán)境。

持續(xù)部署的目標(biāo)是，代碼在任何時(shí)刻都是可部署的，可以進(jìn)入生產(chǎn)階段。

持續(xù)部署的前提是能自動(dòng)化完成測(cè)試、構(gòu)建、部署等步驟。它與持續(xù)交付的區(qū)別，可以參考下圖。

（圖片來源）

四、流程

根據(jù)持續(xù)集成的設(shè)計(jì)，代碼從提交到生產(chǎn)，整個(gè)過程有以下幾步。

4.1 提交

流程的***步，是開發(fā)者向代碼倉庫提交代碼。所有后面的步驟都始于本地代碼的一次提交（commit）。

4.2 測(cè)試（***輪）

代碼倉庫對(duì)commit操作配置了鉤子（hook），只要提交代碼或者合并進(jìn)主干，就會(huì)跑自動(dòng)化測(cè)試。

測(cè)試有好幾種。

• 單元測(cè)試：針對(duì)函數(shù)或模塊的測(cè)試
• 集成測(cè)試：針對(duì)整體產(chǎn)品的某個(gè)功能的測(cè)試，又稱功能測(cè)試
• 端對(duì)端測(cè)試：從用戶界面直達(dá)數(shù)據(jù)庫的全鏈路測(cè)試

***輪至少要跑單元測(cè)試。

4.3 構(gòu)建

通過***輪測(cè)試，代碼就可以合并進(jìn)主干，就算可以交付了。

交付后，就先進(jìn)行構(gòu)建（build），再進(jìn)入第二輪測(cè)試。所謂構(gòu)建，指的是將源碼轉(zhuǎn)換為可以運(yùn)行的實(shí)際代碼，比如安裝依賴，配置各種資源（樣式表、JS腳本、圖片）等等。

常用的構(gòu)建工具如下。

• Jenkins
• Travis
• Codeship
• Strider

Jenkins和Strider是開源軟件，Travis和Codeship對(duì)于開源項(xiàng)目可以免費(fèi)使用。它們都會(huì)將構(gòu)建和測(cè)試，在一次運(yùn)行中執(zhí)行完成。

4.4 測(cè)試（第二輪）

構(gòu)建完成，就要進(jìn)行第二輪測(cè)試。如果***輪已經(jīng)涵蓋了所有測(cè)試內(nèi)容，第二輪可以省略，當(dāng)然，這時(shí)構(gòu)建步驟也要移到***輪測(cè)試前面。

第二輪是全面測(cè)試，單元測(cè)試和集成測(cè)試都會(huì)跑，有條件的話，也要做端對(duì)端測(cè)試。所有測(cè)試以自動(dòng)化為主，少數(shù)無法自動(dòng)化的測(cè)試用例，就要人工跑。

需要強(qiáng)調(diào)的是，新版本的每一個(gè)更新點(diǎn)都必須測(cè)試到。如果測(cè)試的覆蓋率不高，進(jìn)入后面的部署階段后，很可能會(huì)出現(xiàn)嚴(yán)重的問題。

4.5 部署

通過了第二輪測(cè)試，當(dāng)前代碼就是一個(gè)可以直接部署的版本（artifact）。將這個(gè)版本的所有文件打包（ tar filename.tar * ）存檔，發(fā)到生產(chǎn)服務(wù)器。

生產(chǎn)服務(wù)器將打包文件，解包成本地的一個(gè)目錄，再將運(yùn)行路徑的符號(hào)鏈接（symlink）指向這個(gè)目錄，然后重新啟動(dòng)應(yīng)用。這方面的部署工具有Ansible，Chef，Puppet等。

4.6 回滾

一旦當(dāng)前版本發(fā)生問題，就要回滾到上一個(gè)版本的構(gòu)建結(jié)果。最簡單的做法就是修改一下符號(hào)鏈接，指向上一個(gè)版本的目錄。

五、參考鏈接

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

（完）