持續集成之理論篇

本文做者：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（好比 apache二、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 等主流企業開發流程工具。