源寶導讀：“持續(xù)集成”是敏捷最佳實踐中，保證高質(zhì)量交付的關(guān)鍵環(huán)節(jié)之一。本文將分享，在大規(guī)模研發(fā)在線協(xié)同的背景下，如何支撐在線持續(xù)集成的高性能和高可用。

一、什么是持續(xù)集成

????在《持續(xù)集成》一書中，對持續(xù)集成的定義如下：持續(xù)集成是一種軟件開發(fā)實踐。在持續(xù)集成中，團隊成員頻繁集成他們的工作成果，一般每人每天至少集成一次,也可以多次。每次集成會經(jīng)過自動構(gòu)建(包括自動測試)的檢驗，以盡快發(fā)現(xiàn)集成錯誤。自從在團隊中引入這樣的實踐之后，Martin Fowler發(fā)現(xiàn)這種方法可以顯著減少集成引起的問題，并可以加快團隊合作軟件開發(fā)的速度。

集成
????集成就是一些孤立的事物或元素通過某種方式集中在一起，產(chǎn)生聯(lián)系，從而構(gòu)成一個有機整體的過程。知識經(jīng)濟的社會，集成已經(jīng)成了很重要的一個名詞。各行各業(yè)基本都會用到集成。比如汽車行業(yè)，那么復雜的一臺跑車愣是通過一大堆零件組裝起來。對于這些傳統(tǒng)行業(yè)，它們在研發(fā)成功以后，可以通過流水線的方法批量生產(chǎn)進行集成。而在軟件行業(yè)中，集成并不是一個簡單的“搬箱子”的過程。因為軟件工業(yè)是一個知識生產(chǎn)活動，其內(nèi)在邏輯非常復雜，需求又很難一次性確定，完成的產(chǎn)品與最初的設(shè)計往往相差很遠。敏捷宣言中就有一條是說響應變化重于遵循計劃。而且由于軟件行業(yè)的迅猛發(fā)展，軟件變的越來越復雜，單靠個人是根本無法完成。大型軟件為了重用及解耦，往往還需要分成好幾個模塊，這樣集成就成了軟件開發(fā)中不可或缺的一部分。

持續(xù)
????“持續(xù)”并不意味著“一直在運行”，而是“隨時可運行”。在軟件開發(fā)領(lǐng)域，它還包括幾個核心概念/最佳實踐。這些是：

• 自動化流程：實現(xiàn)關(guān)鍵是用自動化流程來處理軟件生產(chǎn)中的方方面面。這包括構(gòu)建、測試、分析、版本控制，以及部署。

• 可重復：如果我們使用的自動化流程在給定相同輸入的情況下始終具有相同的行為，則這個過程應該是可重復的。也就是說，如果我們把某個歷史版本的代碼作為輸入，我們應該得到對應相同的可交付產(chǎn)出。這也假設(shè)我們有相同版本的外部依賴項。理想情況下，這也意味著可以對管道中的流程進行版本控制和重建。

• 快速迭代：“快速”在這里是個相對術(shù)語，但無論軟件更新、發(fā)布的頻率如何，預期的持續(xù)過程都會以高效的方式將源代碼轉(zhuǎn)換為交付物。

組成
????持續(xù)集成一般包括自動編譯、自動構(gòu)建、自動打包、自動部署、自動代碼檢查、自動化測試。

二、為什么要做持續(xù)集成

項目中常見的問題

• 集成時發(fā)現(xiàn)系統(tǒng)無法運行；

• 不同分支之間合并代碼經(jīng)常出錯；

• 加班加點改BUG

• 重復進行手工的部署、調(diào)試、測試、發(fā)布，成；本高，風險大。

團隊文化問題

• 對交付軟件的質(zhì)量意識不足；

• 無法做到優(yōu)先處理失敗的構(gòu)建；

• 工程師文化不足；

• 團隊管理、流程的不足。

持續(xù)集成的優(yōu)點
持續(xù)集成能提升交付效率和交付軟件的質(zhì)量：

• 能及時反饋結(jié)果，盡早發(fā)現(xiàn)問題；

• 通過自動化代替手工，工程師將更多的時間精力放在設(shè)計、需求分析、風險預防等方面；

• 通過持續(xù)集成提高自動化程度來提高效率。

三、持續(xù)集成工具選型

市面上的持續(xù)工具很多，下面列舉了部分

• AnthillPro：商業(yè)的構(gòu)建管理服務(wù)器，提供CI功能；

• Bamboo：商業(yè)的CI服務(wù)器，對于開源項目免費；

• Build Forge：多功能商業(yè)構(gòu)建管理工具，特點：高性能、分布式構(gòu)建；

• Cruise Control：基于java實現(xiàn)的持續(xù)集成構(gòu)建工具；

• CruiseControl.NET：基于C#實現(xiàn)的持續(xù)集成構(gòu)建工具；

• Jenkins：基于java實現(xiàn)的開源持續(xù)集成構(gòu)建工具，現(xiàn)在最流行和知名度最廣泛的持續(xù)集成工具；

• Lunt build：開源的自動化構(gòu)建工具；

• Para Build：商業(yè)的自動化軟件構(gòu)建管理服務(wù)器。

綜合考慮，團隊選取了Jenkins作為持續(xù)集成工具，主要的選型理由是：

• 開源；

• 成熟度活躍度高；

• 分布式；

• 插件豐富、功能強大；

• 團隊成員比較熟悉，都或多或少使用過。

四、研發(fā)協(xié)同平臺持續(xù)集成工作原理

研發(fā)協(xié)同平臺持續(xù)集成整個工作流程如下：

開發(fā)人員提交代碼到代碼倉庫；

研發(fā)協(xié)同控制臺觸發(fā)持續(xù)集成任務(wù)；

持續(xù)集成主節(jié)點進行任務(wù)調(diào)度，將構(gòu)建任務(wù)分發(fā)到構(gòu)建從節(jié)點，將部署任務(wù)分發(fā)到部署從節(jié)點，將質(zhì)量任務(wù)分發(fā)到質(zhì)量從節(jié)點；

構(gòu)建節(jié)點獲取代碼，按照構(gòu)建腳本執(zhí)行，構(gòu)建，打包；

部署節(jié)點按照部署腳本，將服務(wù)部署到容器中；

質(zhì)量節(jié)點按照相應腳本，進行靜態(tài)的代碼掃描、運行單元測試；

持續(xù)集成主節(jié)點通過回調(diào)機制，將任務(wù)狀態(tài)實時回傳到研發(fā)協(xié)同控制臺。

五、研發(fā)協(xié)同平臺持續(xù)集成管道

• 一個持續(xù)集成管道由一系列持續(xù)集成作業(yè)組成；

• 持續(xù)集成管道中的作業(yè)可以是串行，也可以是并行；

• 管道中的作業(yè)由一組命令組成；

• 命令是持續(xù)集成中的最小單元；

• 研發(fā)協(xié)同平臺內(nèi)置了一批命令集；

• 不同的命令組合成不同功能的作業(yè)；

• 不同功能的作業(yè)組合成不同功能的管道；

• 研發(fā)協(xié)同平臺上不同服務(wù)類型的持續(xù)集成使用不同的管道。

六、研發(fā)協(xié)同平臺持續(xù)集成特性

研發(fā)協(xié)同平臺的持續(xù)集成具有如下特性：

• 一鍵集成： 用戶一鍵完成整個集成過程，無需額外的配置和操作，簡單、快捷、方便；

• 開箱即用： 研發(fā)協(xié)同平臺內(nèi)置了公司所有產(chǎn)品持續(xù)集成所需要用到的命令、作業(yè)、管道，用戶無需額外工作，開箱即用；

• 靈活配置： 如果已有持續(xù)集成過程需要調(diào)整，只需調(diào)整已有作業(yè)的命令集，已有管道的作業(yè)即可； 如果有新的服務(wù)類型要做持續(xù)集成，只需根據(jù)命令自由組合新的作業(yè)，根據(jù)作業(yè)自由組合新的管道，即可完成對新服務(wù)類型的持續(xù)集成支持；

• 可擴展：研發(fā)協(xié)同平臺，內(nèi)置了一批命令集、作業(yè)、管道。如果不滿足需求，可以很方便的添加新命令，從而組建新的作業(yè)和管道，實現(xiàn)功能擴展；

• 分布式： 研發(fā)協(xié)同平臺使用持續(xù)集成工具Jenkins的主從特性，主節(jié)點只做任務(wù)的調(diào)度和分發(fā)，具體作業(yè)執(zhí)行在各個從節(jié)點上，實現(xiàn)分布式執(zhí)行；

• 負載平衡： 從節(jié)點分為構(gòu)建節(jié)點、部署節(jié)點、質(zhì)量節(jié)點三類，每一類都由一組節(jié)點組成集群，在主節(jié)點將任務(wù)分發(fā)到從節(jié)點時，可根據(jù)負載規(guī)則分發(fā)到集群中的某一個具體節(jié)點上執(zhí)行。當前支持的負載規(guī)則有：隨機分配、順序分配、按資源使用情況分配、指定具體節(jié)點分配。

七、持續(xù)集成工具Jenkins運維

????研發(fā)協(xié)同平臺持續(xù)集成使用了Jenkins作為持續(xù)集成工具，保障Jenkins的安全、性能、高可用，對Jenkins的持續(xù)運維也是很重要的一部分。

安全

安全矩陣
????在Jenkins管理-> 安全配置-> 訪問控制-> 安全矩陣中，可配置用戶的訪問權(quán)限。

安全漏洞
??? Jenkins是開源軟件，安全漏洞爆出的頻率較高，易于受到攻擊，防止攻擊的一個有效手段就是即使升級Jenkins版本，修補漏洞。

升級
????如何升級，資料很多，這里就不做贅述，但有一些事項需要注意：

• Jenkins主版本升級并不能保證插件的兼容性，升級可能會導致一些插件不可用，要檢查正在使用的插件是否需要同步升級；

• 有些插件在升級后也不能完全保證兼容，升級后也有可能需要做一些相應的調(diào)整和修改，對于在用的插件，在升級前也要做評估；

• Jenkins 141之后版本加入了soft kill的功能，會導致所有的windows節(jié)點執(zhí)行耗時很長甚至卡死。需要在所有的windows主從節(jié)點上的配置文件中添加啟動參數(shù) -DSoftKillWaitSeconds=0 來解決此問題。

性能

• 不要在主節(jié)點上執(zhí)行任務(wù)，主節(jié)點只做任務(wù)的調(diào)度和分發(fā)；

• 清理舊數(shù)據(jù)，在jenkins管理-> 管理舊數(shù)據(jù)中，可清理舊數(shù)據(jù)；

• 不要保留太多的構(gòu)建歷史記錄，可定時清理構(gòu)建歷史。可在在jenkins管理-> 腳本控制臺 執(zhí)行清理腳本來清理構(gòu)建歷史， 下面的示例腳本是保留10條構(gòu)建歷史記錄：

  --保留`10`條構(gòu)建歷史記錄 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()println "total builds: " + builds.size()def j = 0for(int i = numberOfBuildsToKeep; i < builds.size()-j; i++) {builds.get(i).delete()i--j++println "Deleted: " + builds.get(i)} } }

• 在Jenkins的啟動參數(shù)中調(diào)整jvm內(nèi)存大小，默認是512M, 可以根據(jù)需要調(diào)大一些。

高可用與災備

集群
??? Jenkins是主從模式，從節(jié)點可以做集群、負載，從而實現(xiàn)從節(jié)點的高可用，但是主節(jié)點是單節(jié)點，一旦主節(jié)點宕機，會導致Jenkins服務(wù)不可用。Jenkins主節(jié)點本身是不支持集群的，需要通過其他變通方式來實現(xiàn)。當前我們也未實現(xiàn)主節(jié)點高可用，有計劃的是會做主備模式，如果主節(jié)點宕機，可快速切換到備用節(jié)點，恢復服務(wù)。

備份

• 安裝thinBackup插件；

• 在thinBackup插件中，設(shè)置定時備份策略，進行定時備份。

監(jiān)控
性能監(jiān)控

• 安裝monitoring插件；

• 在Jenkins管理-> Jenkins主節(jié)點監(jiān)控中，可查看監(jiān)控Jenkins主節(jié)點性能數(shù)據(jù)。

健康檢查

• 接入研發(fā)協(xié)同的監(jiān)控服務(wù)，檢查Jenkins服務(wù)的可用性。

寫在最后

????當前研發(fā)協(xié)同平臺已經(jīng)能全面支持公司產(chǎn)品各種場景的持續(xù)集成，后續(xù)會進一步落地持續(xù)集成工具jenkins主節(jié)點的高可用，進一步探索支持多種持續(xù)集成工具的必要性和可行性。

------ END ------

作者簡介

陸同學：?架構(gòu)師，負責研發(fā)協(xié)同平臺產(chǎn)品的架構(gòu)規(guī)劃與設(shè)計工作。

也許您還想看

如何解決大批量數(shù)據(jù)保存的性能問題

基于消息的高穩(wěn)定集成架構(gòu)方案

研發(fā)協(xié)同平臺架構(gòu)演進

通過在線編碼提高前端代碼質(zhì)量的探索與實踐

MIP服務(wù)發(fā)現(xiàn)的高可用架構(gòu)實踐

總結(jié)

以上是生活随笔為你收集整理的研发协同平台持续集成实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。