持續集成之理論篇

本文作者：CODING 用戶 - 何健

持續集成 ？——？

大概數周前，突然有學長問我有沒有接觸過“持續集成”。

在我腦海中，這是一個陌生的詞匯，於是百度了解了一番。實際上有開發和部署經驗的小伙伴對持續集成不會非常陌生的，特別是那些喜歡自己寫 webhook 的小伙伴。這篇文章來聊聊持續集成。

互聯網軟件從開發到上線，后續迭代更新，已經有一套近乎標准的流程。其中 持續集成（Continuous integration，簡稱 CI）則是核心流程。像「CODING 持續集成」也直接支持自定義配置流程。

概念

大師 Martin Fowler 對持續集成是這樣定義的：持續集成是一種軟件開發實踐，即團隊開發成員經常集成他們的工作，通常每個成員每天至少集成一次，也就意味着每天可能會發生多次集成。每次集成都通過自動化的構建（包括編譯，發布，自動化測試)來驗證，從而盡快地發現集成錯誤。許多團隊發現這個過程可以大大減少集成的問題，讓團隊能夠更快的開發內聚的軟件。

簡單說，持續集成就是指頻繁自動將代碼集成到主干和生產環境，比如「CODING 持續集成」所實現的功能。

目的

持續集成的目的，快速迭代，保持高質量，避免不必要的成本投入。

優點

1. 快速定位錯誤，測試環節可以及時暴露問題；
2. 避免大幅度偏離主干，借助統一的代碼庫；
3. 減少不必要的成本投入，可以自動化解決的重復乏味的事情，沒必要浪費人力和時間；
4. 實際上還有很多有點，大家慢慢感受啦~

一般步驟

持續集成的核心措施， 集成到主干前， 自動化測試， 只有通過，才可以集成到主干。

成功集成到主干后，也意味着可以部署上線。
這便牽扯出另外兩個相關概念，持續交付、持續部署。

這里一起看一下集成的一般步驟：

1. 設計
2. 開發
3. 測試
4. 發布

每次集成都是這樣的步驟，因此持續集成會時這些基本步驟合體的循環，只要項目還在迭代，我們就會不停重復這個步驟。

持續交付 （Continuous delivery）

這里借用阮一峰老師的說法：

持續交付（Continuous delivery）指的是，頻繁地將軟件的新版本，交付給質量團隊或者用戶，以供評審。如果評審通過，代碼就進入生產階段。
持續交付可以看作持續集成的下一步。它強調的是，不管怎么更新，軟件是隨時隨地可以交付的。

注意，持續交付在自動化測試和集成結束后，不一定會自動部署。如果有自動部署，則是持續部署的概念了。

持續部署 （continuous deployment）

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

其目的時可以隨時部署，迅速投入生產階段。

持續部署這一步，意味着產品和觀眾見面，但是要通過重重考驗，測試、構建、部署等步驟，而且每一步都是自動的。

流程

通常如下幾步：

1. 提交

就是常見的代碼提交到 CODING 倉庫

2. 單元測試

這個過程 通常是一個針對 commit 操作的鈎子，只要由提交，就會跑自動化測試，測試通過才可以推代碼到主干。（這輪測試至少要有單元測試）

常見測試：

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

3. 構建

第一輪測試通過，代碼可以成功合並到主干，交付。

那么接下來，就要構建（build），進入第二輪測試。

但是，構建並不是絕對必須的過程，構建就是為了讓源碼變成可以運行的程序或代碼。如果是 java、golang 項目，通常要 build 后才可以運行。但如果是 php、python，可能並沒有構建過程，只要更新代碼到對應的 cgi 容器的工程目錄就可以了。

構建過程，我們可以自己寫一些腳本和接口，掛到對應的鈎子里。當然，也可以用一些成熟的構建工具：

• jenkins （開源免費）
• Travis
• codeship （開源免費）
• Strider
• 「CODING 持續集成」

4. 全面測試

這輪測試 ，應該是一次全面測試，除了前面提到的自動化測試，還應該包含一些無法自動化測試的部分。如果第一輪測試已經很全面（意味着前一步和第一輪測試合並了，不構建，自然無法全面測試），那么這輪測試可以作為第一輪測試的補集存在。

這里需要注意的是，測試的覆蓋率。每次版本更新，更新點都應測試到位。

要素

1. 統一的代碼庫
2. 自動構建
3. 自動測試
4. 每個人每天都要向代碼庫主干提交代碼
5. 每次代碼遞交后都會在持續集成服務器上觸發一次構建
6. 保證快速構建
7. 模擬生產環境的自動測試
8. 每個人都可以很容易的獲取最新可執行的應用程序
9. 每個人都清楚正在發生的狀況
10. 自動化的部署

原則

1. 所有的開發人員需要在本地機器上做本地構建，然后再提交的版本控制庫中，從而確保他們的變更不會導致持續集成失敗。
2. 開發人員每天至少向版本控制庫中提交一次代碼。
3. 開發人員每天至少需要從版本控制庫中更新一次代碼到本地機器。
4. 需要有專門的集成服務器來執行集成構建，每天要執行多次構建。
5. 每次構建都要 100% 通過。
6. 每次構建都可以生成可發布的產品。
7. 修復失敗的構建是優先級最高的事情。
8. 測試是未來，未來是測試

小結

從開發到上線，整體流程：

持續集成——>持續交付——>持續部署

可以用「CODING 持續集成」進行實踐。

Jenkins 和持續集成什么關系

Jenkins 是一個開源軟件項目，是基於 Java 開發的一種持續集成工具，用於監控持續重復的工作，旨在提供一個開放易用的軟件平台，使軟件的持續集成變成可能。

沒錯，它就是一個具體的持續集成解決方案。基於 Java 實現。
可以實現：

1. 持續版本發布/測試；
2. 監控外部調用執行的工作；

持續集成和 webhook 什么關系

說到這里，一些有 php 開發經驗的小伙伴很容易聯想到寫 webhook。

沒錯，php 程序通常由 Http Server（比如 apache2、nginx 等）通過反響代理 fpm-cgi 或者直接內置 cgi 來執行 php 程序。這個過程更像是直接請求了 html 文檔。說這里是因為，一些 php 寫手為了方便更新線上代碼，並不想每次都手動 scp 命令上傳新的代碼，特別時有時候有些代碼可能是有問題的。這時候，大家都想到用版本管理，git 就是很好的選擇，其中 github 和 CODING 都是不錯的選擇。

我們的話題是持續集成，為什么會突然扯到 php 和 git 呢？

那是因為，github 和 CODING 很早就都支持了 webhook 功能。換句話說，我們可以通過開放一個特別的接口，這個接口就一個功能，執行一系列操作，每當接口被調用時，接口可以執行我們預設好的一系列任務指令。這樣，我們每次寫好代碼，只要 push 到倉庫，觸發 webhook，github 等平台就會去請求我們開放的接口，用來執行更新代碼和重啟服務等操作。

簡單說，我們給服務器上留了一個“小工”，指派給他一個接頭人，接到信號就做預先安排好的事兒。

這個過程，是不是很像持續部署最后自動部署的階段？

沒錯，就是這樣，這個過程很可能時沒有自動測試環節，直接自動交付，自動部署。

當然，如果 webhook 寫復雜點，完全可以配合一些腳本命令做自己的一套 CI\CD。

總結

CODING 是一個面向開發者的雲端開發平台，提供 Git/SVN 代碼托管、任務管理、在線 WebIDE、Cloud Studio、開發協作、文件管理、Wiki 管理、提供個人服務及企業服務，其中實現了 DevOps 流程全自動化，為企業提供軟件研發全流程管理工具，打通了從團隊構建、產品策划、開發測試到部署上線的全過程。「CODING 持續集成」集成了 Jenkins 等主流企業開發流程工具。