研發協同平臺持續整合之Jenkins實踐
導讀
研發協同平臺有兩個核心目標，一是提高研發效率 ，二是提高研發質量，要實現這兩個核心目標，實現持續整合是關鍵之一。
什麼是持續整合
在《持續整合》一書中，對持續整合的定義如下：持續整合是一種軟體開發實踐。在持續整合中，團隊成員頻繁整合他們的工作成果，一般每人每天至少整合一次,也可以多次。每次整合會經過自動構建(包括自動測試)的檢驗，以儘快發現整合錯誤。自從在團隊中引入這樣的實踐之後，Martin Fowler發現這種方法可以顯著減少整合引起的問題，並可以加快團隊合作軟體開發的速度。
1、整合
整合就是一些孤立的事物或元素通過某種方式集中在一起，產生聯絡，從而構成一個有機整體的過程。知識經濟的社會，整合已經成了很重要的一個名詞。各行各業基本都會用到整合。比如汽車行業，那麼複雜的一臺跑車愣是通過一大堆零件組裝起來。對於這些傳統行業，它們在研發成功以後，可以通過流水線的方法批量生產進行整合。而在軟體行業中，整合並不是一個簡單的“搬箱子”的過程。因為軟體工業是一個知識生產活動，其內在邏輯非常複雜，需求又很難一次性確定，完成的產品與最初的設計往往相差很遠。敏捷宣言中就有一條是說響應變化重於遵循計劃。而且由於軟體行業的迅猛發展，軟體變的越來越複雜，單靠個人是根本無法完成。大型軟體為了重用及解耦，往往還需要分成好幾個模組，這樣整合就成了軟體開發中不可或缺的一部分。
2、持續
“持續”並不意味著“一直在執行”，而是“隨時可執行”。在軟體開發領域，它還包括幾個核心概念/最佳實踐。這些是：
自動化流程：實現關鍵是用自動化流程來處理軟體生產中的方方面面。這包括構建、測試、分析、版本控制，以及部署。
可重複：如果我們使用的自動化流程在給定相同輸入的情況下始終具有相同的行為，則這個過程應該是可重複的。也就是說，如果我們把某個歷史版本的程式碼作為輸入，我們應該得到對應相同的可交付產出。這也假設我們有相同版本的外部依賴項。理想情況下，這也意味著可以對管道中的流程進行版本控制和重建。
快速迭代：“快速”在這裡是個相對術語，但無論軟體更新、釋出的頻率如何，預期的持續過程都會以高效的方式將原始碼轉換為交付物。
3、組成
持續整合一般包括自動編譯、自動構建、自動打包、自動部署、自動程式碼檢查、自動化測試
為什麼要做持續整合
專案中常見的問題
- 整合時發現系統無法執行
- 不同分之之間合併程式碼經常出錯
- 加班加點改BUG
- 重複進行手工的部署、除錯、測試、釋出，成本高，風險大
團隊文化問題
- 對交付軟體的質量意識不足
- 無法做到優先處理失敗的構建
- 工程師文化不足
- 團隊管理、流程的不足
持續整合的優點
持續整合能提升交付效率和交付軟體的質量
- 及時反饋結果，儘早發現問題
- 自動化代替手工，工程師將更多的時間精力放在設計、需求分析、風險預防等方面
- 通過持續整合提高自動化程度來提高效率
持續整合工具選型
市面上的持續工具很多，下面列舉了部分
- AnthillPro：商業的構建管理伺服器，提供C功能
- Bamboo：商業的CI伺服器，對於開源專案免費
- Build Forge：多功能商業構建管理工具，特點：高效能、分散式構建
- Cruise Control：基於java實現的持續整合構建工具
- CruiseControl.NET：基於C#實現的持續整合構建工具
- Jenkins：基於java實現的開源持續整合構建工具，現在最流行和知名度最廣泛的持續整合工具
- Lunt build：開源的自動化構建工具
- Para Build：商業的自動化軟體構建管理伺服器
綜合考慮，團隊選取了Jenkins作為持續整合工具，主要的選型理由是：
- 開源
- 成熟度活躍度高
- 分散式
- 外掛豐富、功能強大
- 團隊成員比較熟悉，都或多或少使用過
研發協同平臺持續整合工作原理
研發協同持續整合整個工作流程如下
- 開發人員提交程式碼到程式碼倉庫
- 研發協同控制檯觸發持續整合任務
- 持續整合主節點進行任務排程，將構建任務分發到構建從節點，將部署任務分發到部署從節點，將質量任務分發到質量從節點
- 構建節點獲取程式碼，按照構建指令碼執行，構建，打包
- 部署節點按照部署指令碼，將服務部署到容器中
- 質量節點按照相應指令碼，進行靜態的程式碼掃描、執行單元測試
- 持續整合主節點通過回撥機制，將任務狀態實時回傳到研發協同控制檯
研發協同平臺持續整合管道
持續整合管道圖
持續整合作業圖
- 一個持續整合管道由一系列持續整合作業組成
- 持續整合管道中的作業可以是序列，也可以是並行
- 管道中的作業由一組命令組成
- 命令是持續整合中的最小單元
- 研發協同平臺內建了一批命令集
- 不同的命令組合成不同功能的作業
- 不同功能的作業組合成不同功能的管道
- 研發協同平臺上不同服務型別的持續整合使用不同的管道
研發協同平臺持續整合特性
研發協同平臺的持續整合具有如下特性：
- 一鍵整合： 使用者一鍵完成整個整合過程，無需額外的配置和操作，簡單、快捷、方便
- 開箱即用： 研發協同平臺內建了公司所有產品持續整合所需要用到的命令、作業、管道，使用者無需額外工作，開箱即用
- 靈活配置： 如果已有持續整合過程需要調整，只需調整已有作業的命令集，已有管道的作業即可； 如果有新的服務型別要做持續整合，只需根據命令自由組合新的作業，根據作業自由組合新的管道，即可完成對新服務型別的持續整合支援
- 可擴充套件：研發協同平臺，內建了一批命令集、作業、管道。如果不滿足需求，可以很方便的新增新命令，從而組建新的作業和管道，實現功能擴充套件
- 分散式： 研發協同平臺使用持續整合工具Jenkins的主從特性，主節點只做任務的排程和分發，具體作業執行在各個從節點上，實現分散式執行
- 負載平衡： 從節點分為構建節點、部署節點、質量節點三類，每一類都由一組節點組成叢集，在主節點將任務分發到從節點時，可根據負載規則分發到叢集中的某一個具體節點上執行。當前支援的負載規則有：隨機分配、順序分配、按資源使用情況分配、指定具體節點分配
持續整合工具Jenkins運維
研發協同平臺持續整合使用了Jenkins作為持續整合工具，保障Jenkins的安全、效能、高可用，對jenkins的持續運維也是很重要的一部分
安全
安全矩陣
在Jenkins管理-> 安全配置-> 訪問控制-> 安全矩陣中，可配置使用者的訪問許可權
安全漏洞
Jenkins是開源軟體，安全漏洞爆出的頻率較高，易於受到攻擊，防止攻擊的一個有效手段就是即使升級Jenkins版本，修補漏洞
升級
如何升級，資料很多，這裡就不做贅述，但有一些事項需要注意：
- Jenkins主版本升級並不能保證外掛的相容性，升級可能會導致一些外掛不可用，要檢查正在使用的外掛是否需要同步升級
- 有些外掛在升級後也不能完全保證相容，升級後也有可能需要做一些相應的調整和修改，對於在用的外掛，在升級前也要做評估
- Jenkins 141之後版本加入了softkill的功能，會導致所有的windows節點執行耗時很長甚至卡死。需要在所有的windows主從節點上的配置檔案中新增啟動引數 -DSoftKillWaitSeconds=0 來解決此問題。
效能
- 不要在主節點上執行任務，主節點只做任務的排程和分發
- 清理舊資料，在jenkins管理-> 管理舊資料中，可清理舊資料
- 不要保留太多的構建歷史記錄，可定時清理構建歷史。可在在jenkins管理-> 指令碼控制檯 執行清理指令碼來清理構建歷史， 下面的示例指令碼是保留10條構建歷史記錄
def numberOfBuildsToKeep = 10
Jenkins.instance.getAllItems(AbstractItem.class).each {
if( it.class.toString() != "class com.cloudbees.hudson.plugins.folder.Folder" && it.class.toString() != "class org.jenkinsci.plugins.workflow.multibranch.WorkflowMultiBranchProject") {
builds = it.getBuilds()
def j = 0
for(int i = numberOfBuildsToKeep; i < builds.size()-j; i++) {
builds.get(i).delete()
i--
j++
println "Deleted: " + builds.get(i)
}
}
}- 在Jenkins的啟動引數中調整jvm記憶體大小，預設是512M, 可以根據需要調大一些
高可用與災備
叢集
Jenkins是主從節點，從節點可以做叢集、負載，從而實現從節點的高可用，但是主節點是單節點，一旦主節點宕機，會導致Jenkins服務不可用。 Jenkins主節點本身是不支援叢集的，需要通過其他變通方式來實現。當前我們也未實現主節點高可用，有計劃的是會做主備模式，如果主節點宕機，可快速切換到備用節點，恢復服務
備份
- 安裝thinBackup外掛
- 在thinBackup外掛中，設定定時備份策略，進行定時備份
監控
效能監控
- 安裝monitorign外掛
- 在Jenkins管理-> Jenkins主節點監控中，可檢視監控jenkins主節點效能資料
健康檢查
- 接入研發協同的監控服務，檢查jenins服務的可用性
寫在最後
當前研發協同平臺已經能全面支援公司產品各種場景的持續整合，後續會進一步落地持續整合工具jenkins主節點的高可用，進一步探索支援多種持續整合工具的必要性和可行性