導讀
研發協同平台有兩個核心目標，一是提高研發效率 ，二是提高研發質量，要實現這兩個核心目標，實現持續集成是關鍵之一。
什么是持續集成
在《持續集成》一書中，對持續集成的定義如下：持續集成是一種軟件開發實踐。在持續集成中，團隊成員頻繁集成他們的工作成果，一般每人每天至少集成一次,也可以多次。每次集成會經過自動構建(包括自動測試)的檢驗，以盡快發現集成錯誤。自從在團隊中引入這樣的實踐之后，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主節點的高可用，進一步探索支持多種持續集成工具的必要性和可行性。