持續集成之理論篇


本文作者: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 容器的工程目錄就可以了。

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

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 等主流企業開發流程工具。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM