DevOps - 持續集成（Continuous Integration）

時間 2019-12-05

標籤 devops 持續集成 continuous integration 简体版

原文原文鏈接

持續集成

簡介

持續集成（Continuous integration，簡稱CI）是軟件的開發和發佈標準流程中最重要的部分。
做爲一種開發實踐，在CI中能夠經過自動化等手段高頻率地去獲取產品反饋並響應反饋的過程。
簡單來講，就是持續不斷地（一天屢次）將代碼合併（集成）到主幹源碼倉庫，讓產品能夠快速迭代，同時保持高質量。html

代碼每次集成到主幹以前，必須經過自動化測試，以便快速發現和定位錯誤。
持續集成並不能消除錯誤，而是讓它們很是容易發現和改正。git

優勢

縮減開發週期，快速迭代版本
　儘早的持續集成，儘快進入迭代之中，就能夠儘早的暴露出問題，提前解決，儘可能在規定時間內完成任務。web
自動化流水線操做帶來的高效
CI的精髓在於持續，持續意味着自動化。
　自動化驗證代碼變動的過程，能夠在軟件開發的早期發現缺陷和與其餘代碼和組件的集成問題。服務器
隨時可部署
　高頻率的集成能夠儘量地保證隨時部署上線，縮短開發複雜軟件的市場交付時間。架構
極大程度避免低級錯誤
　減小大塊內容合併到主幹分支的狀況，避免代碼合併衝突和沒法預料的行爲。
　低級錯誤：編譯錯誤，安裝問題，接口問題，性能問題等。函數

難點

遷移遺留代碼到現有CI系統，須要的投入一般在預料以外
在文化和組織上若是沒有采用敏捷原則或DevOps的工做方式，那麼極可能沒有持續不斷的提交，那麼CI的存在乎義不大
隨着業務增加、工具的更替、技術的演進，CI系統也必然隨之改動，每每會致使階段性的不穩定和人力物力的耗費
若是CI的基本設定不到位，開發流程將會增長特別的開銷

注意點

CI流程的觸發方式：

跟蹤觸發式：在每次提交到源碼版本管理系統時觸發
計劃任務：預配置好的計劃，例如一次凌晨的構建
手動：不管是經過CI服務器的管理界面仍是腳本，用戶能夠手工執行CI工做流

代碼審覈

可在持續集成服務器裏使用代碼分析工具（例如Sonar）來執行自動代碼審查
自動代碼審查經過後，可發起一我的工代碼審查，揪出那些自動審查沒法找出的問題，即驗證業務需求，架構問題，代碼是否可讀，以及是否易於擴展。
可靈活配置代碼審覈策略，例如：若是某些人沒有審查代碼便阻止對主幹分支的任何提交。
最經常使用的工具是Gerrit

CI流程

典型的CI流程

一個完整的CI系統應該包含3個基本模塊：工具

一個能夠自動構建的過程，自動編譯代碼，能夠自動分發，部署和測試。
一個代碼倉庫，例如Git。
一個持續集成的服務器。

通用的CI流程

簽出代碼：
從源碼管理系統裏簽出或者克隆最新的代碼到本地開發環境gitlab
提交（commit）：
基於主幹分支建立一個新的功能分支，並在此分支編寫代碼，並向倉庫提交代碼性能
測試（第1輪）：
代碼倉庫對commit操做配置了鉤子（hook），每一次提交代碼都會觸發測試
單元測試（針對函數或模塊的測試）和功能測試（集成測試）將會被執行、根據須要設置是否執行端對端測試
通常來講，這些測試也會被打包到代碼裏。單元測試
構建（build）：
經過測試（第1輪）後，將源碼轉換爲能夠運行的實際代碼，好比安裝依賴，配置各類資源等
實現一個CI流程的惟一必要條件即是得有一個自動構建系統。
源代碼通常是自包含構建的，即CI流程所需的構建腳本是放在源碼倉庫裏的。
測試（第2輪）：
以自動化爲主的全面測試，包括單元測試和集成測試，必要時作端對端測試，確保新版本的每個更新點都必須測試到
合併：
經過測試（第2輪）後，將代碼更新集成到主幹
回滾：
若是當前版本發生問題，就回滾到上一個版本的構建結果
通常來講，CI服務器會配置成在遇到故障時發送郵件相關人員，能夠快速知曉故障而且儘快採起更正措施。