本文作者：CODING 用戶 - 何健

持續集成 ？——？

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

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

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

概念

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

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

目的

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

優點

快速定位錯誤，測試環節可以及時暴露問題；

避免大幅度偏離主干，借助統一的代碼庫；

減少不必要的成本投入，可以自動化解決的重復乏味的事情，沒必要浪費人力和時間；

實際上還有很多有點，大家慢慢感受啦~

一般步驟

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

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

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

設計

開發

測試

發布

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

持續交付 （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. 全面測試

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

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

要素

統一的代碼庫

自動構建

自動測試

每個人每天都要向代碼庫主干提交代碼

每次代碼遞交后都會在持續集成服務器上觸發一次構建

保證快速構建

模擬生產環境的自動測試

每個人都可以很容易的獲取最新可執行的應用程序

每個人都清楚正在發生的狀況

自動化的部署

原則

所有的開發人員需要在本地機器上做本地構建，然后再提交的版本控制庫中，從而確保他們的變更不會導致持續集成失敗。

開發人員每天至少向版本控制庫中提交一次代碼。

開發人員每天至少需要從版本控制庫中更新一次代碼到本地機器。

需要有專門的集成服務器來執行集成構建，每天要執行多次構建。

每次構建都要 100% 通過。

每次構建都可以生成可發布的產品。

修復失敗的構建是優先級最高的事情。

測試是未來，未來是測試

小結

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

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

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

Jenkins 和持續集成什么關系

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

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

持續版本發布/測試；

監控外部調用執行的工作；

持續集成和 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 寫復雜點，完全可以配合一些腳本命令做自己的一套 CICD。

總結

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

總結

以上是生活随笔為你收集整理的持续集成之理论篇的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。