本文作者: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 寫復雜點,完全可以配合一些腳本命令做自己的一套 CI\CD。
總結
CODING 是一個面向開發者的雲端開發平台,提供 Git/SVN 代碼托管、任務管理、在線 WebIDE、Cloud Studio、開發協作、文件管理、Wiki 管理、提供個人服務及企業服務,其中實現了 DevOps 流程全自動化,為企業提供軟件研發全流程管理工具,打通了從團隊構建、產品策划、開發測試到部署上線的全過程。「CODING 持續集成」集成了 Jenkins 等主流企業開發流程工具。