中國銀行DevOps標準化實踐

　　摘要：高質量發展是全面建設社會主義現代化國家的首要任務。中國銀行的資訊科技體系擔負著商業銀行軟體系統與應用的開發、測試、維護管理和實施工作。在數字化轉型，實施DevOps是推動業務、技術的敏捷、高質量發展是中國銀行資訊科技體系的工作重點之一。

　　DevOps應用體系是以“價值交付”為核心，持續改進為目標，同時滿足高效開發、自動運維、持續釋出、團隊協作，不斷最佳化端到端交付流水線，逐步實現隨時交付，支撐業務高質量發展。經過實踐，提出以特性分支為基礎的，質量內建“七步法”，並形成一套符合中國銀行各產品線的DevOps標準化流程，提升產品建設質量，加快敏捷響應速度。

　　關鍵詞：DevOps; 特性分支；流水線；質量內建

　　 一、轉型之痛

　　在數字化轉型的大背景下,中國銀行已開展DevOps能力成熟度模型評估，聚焦於將應用的開發、測試、部署和運營統一起來，打通了開發、測試、運維端到端的流水線，助力業務部門更快地響應市場變化，滿足客戶需求。然而也面臨著一系列的挑戰。

　　（1）中國銀行業務需求覆蓋廣，資訊科技人員眾多，各個產品程式碼組織、實現、部署、環境管理等存在差異，在持續互動方面並沒有統一標準和規範。

　　（2）中國銀行軟體中心已全面從傳統瀑布式開發轉向敏捷開發模式，舊的瀑布模式的準則已不適用，但是適用敏捷模式開發的規則還未統一。

　　一是有些產品採用主幹開發模式，提交頻繁，衝突多，主幹程式碼不穩定，一旦出問題，所有工作被阻塞。

　　二是質量落地不可見，依靠制定規範文件，質量管理依賴於人，質量活動可跳過。程式碼交付質量也缺少量化方法，主觀判斷大於客觀準則。

　　三是問題反饋較慢，很多問題在測試階段才能被發現，修復成本較高。

　　面臨上述困難和挑戰，有必要實施適合各產品線的規範化、標準化持續交付工藝流程。為此，藉著中國銀行企業級架構建設專案，開展了標準化、規範化探索實踐。

　　 二、痛則思變

　　針對面臨的痛點，透過探索實踐，提出開發測試一體化的DevOps標準化流程工藝方案。以特性分支策略為基礎，採用“分支開發，主幹釋出”的開發模式。以質量內建為原則，透過分級構建與階段性檢查，將質量控制落實到開發的各個階段以加速質量反饋，做到了缺陷前移和高質量交付，實現了降低成本、提高開發效率的最終目標，貫徹了開發測試一體化的理念。

　　1.規範化管理

　　規範分支管理策略。採用“分支開發，主幹釋出”的特性分支開發策略，把控與敏捷故事開發相匹配的分支粒度，解決了主幹分支開發造成的程式碼衝突多、不穩定的問題。為此，將程式碼分支進行了分類，主要有以下5類分支：

　　Master，用於生產版本的釋出。

　　Release，用於功能版本的釋出。

　　Develop，用於開發環境的版本釋出，是迭代開發的主幹分支。

　　Feature，用於特性功能開發，即特性分支。

　　Fix，專門用於Bug修復的分支。

　　為了確保開發人員按照設計質量控制流程提交程式碼，確保標準化流程得到落實，對Master、Release、Develop分支僅允許開發人員透過發起程式碼合併請求來提交修改，而Feature、Fix分支不設限制，允許開發人員直接進行程式碼推送，這樣既保證了重要分支的穩定性，同時也保證了開發的靈活性。

　　2.規範化執行

　　在規範分支策略的基礎上，透過流水線規範化執行，由人為管控轉化為自動化流程管控，確保質量標準嚴格落實到開發過程，落實到應用開發的各個階段，實現提測前的質量內建。我們將開發流程拆分成七步，並在每一步中，透過制定相應的質量標準，嚴格按照質量標準進行檢測，稱為質量內建七步法（如圖1所示）。　　

圖1 質量內建“七步法開發”示意

　　質量檢查主要有三類，分別是本地工具檢查、人工評審、流水線檢查。其中本地檢查是一個低成本、高效率的方案，並可以根據不同的開發語言靈活選用檢查工具。人工評審的步驟是為了保證程式碼實現的業務功能的正確性，保證避免程式碼的功能邏輯的錯誤。流水線檢查則分別提供了日常質量反饋，合併程式碼檢查，部署程式碼檢查的功能，是整個開發流程質量把控的重要組成部分。

　　第一步：特性分支拉取

　　根據敏捷迭代故事建立特性分支，一般以故事或子任務維度建立特性分支，要求粒度小，能夠三天內開發完成合併到主分支，特性分支需每日都要拉取主分支最新程式碼，防止長時間封閉開發造成程式碼衝突。質量檢查點，規範分支命名。例如feat/內容/開發人員/日期/批次任務。

　　第二步：原生程式碼檢查

　　原生程式碼修改提交後，觸發對提交資訊的規範性檢查，再透過靜態程式碼掃描工具對本次增量程式碼進行掃描。本地檢查具備效率高，糾錯成本低的優點。原生程式碼檢查不同開發語言可以選擇適合自己產品的檢查規則。要求質量標準：一是提交資訊符合規範；二是程式碼符合語法規則。

　　第三步：CI整合流水線

　　特性分支程式碼提交後，會觸發特性分支流水線檢查，並透過質量紅線檢測不符合質量規範的程式碼。這個節點的質量控制點在Sonar程式碼掃描之後，設定了日常構建質量紅線，包括0bug，0漏洞，0壞味道，也設定分支覆蓋率指標和案例100%透過。

　　第四步：預編譯流水線

　　由於Develop主幹分支為保護分支，因此，特性分支功能程式碼編寫完成之後，開發人員需發起合併到Develop分支請求，當開發人員發起合併請求時，Git會自動建立一條對應的評審記錄單，也會觸發對應分支合併請求的預編譯流水線。這裡會要求開發人員將本次合併的流水線執行情況貼在記錄單上面方便後面評審。

　　預編譯流水線質量控制點和標準主要包括：

　　（1）程式碼合併無衝突，若衝突直接停止。

　　（2）透過日常構建質量紅線以及構建過程無問題。

　　第五步：程式碼評審

　　評審人員在看到對應的流水線執行成功記錄之後，進行程式碼評審，這個階段主要是人工程式碼走查為主；程式碼評審質量控制點主要是程式碼業務邏輯走查以及單元測試有效性走查。要求是符合團隊內的程式碼走查checklist，滿足業務邏輯要求，單元測試有效。評審透過才可以合併程式碼。能夠保證每次變更都必須走查，走查也及時，範圍清晰，基於GIT系統溝通成本低，缺陷修復成本也低。

　　第六步：CD流水線

　　評審透過之後，流水線使用變基合併分支，自動觸發部署流水線，成功之後通知迭代測試人員對故事測試。

　　CD流水線質量控制點和質量標準主要是質量紅線設定，除了要透過日常構建質量紅線之外，還要透過安全外掛的質量紅線。

　　第七步：迭代測試

　　部署流水線透過後自動完成程式碼部署，並觸發ATP自動化測試元件，同時開發人員可將對應迭代故事交付測試。

　　3.完善DevOps工具鏈

　　除了以特性分支策略的質量內建七步法，各產品線可以根據產品特點，持續自研相關工具，豐富DevOps工具鏈，進一步提升開發效率，減少人工出錯的機會。如SQL指令碼、測試指令碼編寫等。

　　 三、變則通贏

　　透過實際專案開展DevOps標準化工藝的實踐，並總結經驗，取得成效如下：

　　1.缺陷前移

　　透過實踐，統計發現迭代開發階段發現的缺陷（包括質量紅線攔截、程式碼複查）佔比76.5%，迭代測試階段發現的缺陷佔比18.1%。在DevOps標準化工藝實施下專案的缺陷前移效果顯著。

　　絕大多數的程式碼質量問題在開發階段透過本地檢查、預編譯流水線和程式碼合併前評審等環節發現並解決，有效降低解決問題的成本，交付測試的程式碼質量得到提高。

　　2.質量保障

　　採用主分支開發的時候，流水線失敗比例非常高，執行成功率僅為65.7%。開發人員一直忙於解決流水線紅燈問題，由於多人並行提交或合併程式碼導致定位問題更加困難，很難保證CI紀律。

　　在採用預編譯流水線之後，透過程式碼掃描和預合併編譯等手段檢查提交程式碼質量，流水線執行成功率達到99.3%。開發人員透過使用預編譯流水線保障部署成功率，提高程式碼交付質量，保障迭代測試環境的穩定。

　　3.反饋加速

　　未採用分級構建，開發人員前期使用單流水線序列的方式一次性完成程式碼提取，程式碼檢查、單元測試、程式碼編譯和部署等多個環節，每次等待流水線執行完成的時間需16分鐘以上。同時由於單一序列的方式，各階段反饋質量問題速度較慢，無法及時跟進解決。

　　採用分級構建方式，將原有的單流水線序列分拆到不同環節的流水線上並行處理，資源利用率提高，整體耗費時間得到有效降低，各階段發現的缺陷問題均能及時獲得反饋，更早被開發人員捕獲並解決，解決問題成本更低。

　　分級構建前後如圖2所示。　　

圖2 分級構建前後示意

　　透過實踐驗證，為中國銀行數字化轉型的DevOps提供標準化參考指南，除了實現了缺陷前移，質量內建，更重要的意義在於此標準化工藝流程可以很好地遮蔽因開發人員的水平參差不齊而帶來的差異，保證開發效率和質量。

　　標準化不是終點，而是新的起點，未來在DevOps標準化過程，將逐步完善各個階段的功能和DevOps工具鏈，推動自動化端到端測試等，進一步提升自動化率，推動產品的高質量建設與交付。