概述

互聯網軟件的開發和發布，已經形成了一套標準流程，最重要的組成部分就是持續集成（Continuous integration，簡稱CI）。

持續集成

持續集成指的是，頻繁地（一天多次）將代碼集成到主干。它的好處主要有兩個：

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

Martin Fowler 說過，"持續集成并不能消除 Bug，而是讓它們非常容易發現和改正。"

持續集成強調開發人員提交了新代碼之后，立刻進行構建、（單元）測試。根據測試結果，我們可以確定新代碼和原有代碼能否正確地集成在一起。

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

持續交付

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

持續交付可以看作持續集成的下一步。它強調的是，不管怎么更新，軟件是隨時隨地可以交付的。

持續交付在持續集成的基礎上，將集成后的代碼部署到更貼近真實運行環境的「類生產環境」（production-like environments）中。比如，我們完成單元測試后，可以把代碼部署到連接數據庫的 Staging 環境中更多的測試。如果代碼沒有問題，可以繼續手動部署到生產環境中。

持續部署

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

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

持續部署的前提是能自動化完成測試、構建、部署等步驟。

持續集成的操作流程

概述

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

提交

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

測試（第一輪）

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

測試的種類：

• 單元測試：針對函數或模塊的測試
• 集成測試：針對整體產品的某個功能的測試，又稱功能測試
• 端對端測試：從用戶界面直達數據庫的全鏈路測試

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

構建

通過第一輪測試，代碼就可以合并進主干，就算可以交付了。

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

常用的構建工具如下：

• Jenkins
• Travis
• Codeship
• Strider

Jenkins 和 Strider 是開源軟件，Travis 和 Codeship 對于開源項目可以免費使用。它們都會將構建和測試，在一次運行中執行完成。

測試（第二輪）

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

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

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

部署

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

生產服務器將打包文件，解包成本地的一個目錄，再將運行路徑的符號鏈接（symlink）指向這個目錄，然后重新啟動應用。這方面的部署工具有Ansible，Chef，Puppet等。

回滾

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

使用 GitLab 持續集成

本節視頻

簡介

從 GitLab 8.0 開始，GitLab CI 就已經集成在 GitLab 中，我們只要在項目中添加一個 .gitlab-ci.yml 文件，然后添加一個 Runner，即可進行持續集成。 而且隨著 GitLab 的升級，GitLab CI 變得越來越強大。

概念

Pipeline

一次 Pipeline 其實相當于一次構建任務，里面可以包含多個流程，如安裝依賴、運行測試、編譯、部署測試服務器、部署生產服務器等流程。

任何提交或者 Merge Request 的合并都可以觸發 Pipeline，如下圖所示：

+------------------+           +----------------+
|                  |  trigger  |                |
|   Commit / MR    +---------->+    Pipeline    |
|                  |           |                |
+------------------+           +----------------+

Stages

Stages 表示構建階段，說白了就是上面提到的流程。我們可以在一次 Pipeline 中定義多個 Stages，這些 Stages 會有以下特點：

• 所有 Stages 會按照順序運行，即當一個 Stage 完成后，下一個 Stage 才會開始
• 只有當所有 Stages 完成后，該構建任務 (Pipeline) 才會成功
• 如果任何一個 Stage 失敗，那么后面的 Stages 不會執行，該構建任務 (Pipeline) 失敗

因此，Stages 和 Pipeline 的關系就是：

+--------------------------------------------------------+
|                                                        |
|  Pipeline                                              |
|                                                        |
|  +-----------+     +------------+      +------------+  |
|  |  Stage 1  |---->|   Stage 2  |----->|   Stage 3  |  |
|  +-----------+     +------------+      +------------+  |
|                                                        |
+--------------------------------------------------------+

Jobs

Jobs 表示構建工作，表示某個 Stage 里面執行的工作。我們可以在 Stages 里面定義多個 Jobs，這些 Jobs 會有以下特點：

• 相同 Stage 中的 Jobs 會并行執行
• 相同 Stage 中的 Jobs 都執行成功時，該 Stage 才會成功
• 如果任何一個 Job 失敗，那么該 Stage 失敗，即該構建任務 (Pipeline) 失敗

所以，Jobs 和 Stage 的關系圖就是：

+------------------------------------------+
|                                          |
|  Stage 1                                 |
|                                          |
|  +---------+  +---------+  +---------+   |
|  |  Job 1  |  |  Job 2  |  |  Job 3  |   |
|  +---------+  +---------+  +---------+   |
|                                          |
+------------------------------------------+