知識星球
背景
傳統的銀行IT系統研發流程從需求提出到產品交付往往具有較長的研發週期，縱觀銀行當下麵臨的市場環境，個人信貸消費升級，資管需求旺盛，普惠金融成為國家戰略，來自銀行同業和網際網路金融的壓力撲面而來，誰先推出符合市場需求的產品誰就佔領了先機，對銀行IT研發的快速交付能力提出了新的要求和挑戰。
傳統銀行IT系統研發過程中的弊端主要體現在研發流程不連貫難追溯、人工處理效率低時效差、缺乏有效的程式碼審查機制、人力資源浪費等，針對上述問題，我們基於持續整合、持續交付的理念，設計了針對某銀行大型管理系統（下稱C系統）的CI/CD流水線，開發了一系列核心元件，基於TFS (現已改名為 Azure DevOps Server)實現了端到端、線上化、全自動的持續交付。
作者：葛江浩、宋紹磊、王麗敏
供職於中國農業銀行研發中心，從事信貸管理領域系統研發工作，致力於銀行大型IT系統端到端全流程敏捷轉型的研究與實踐。
C系統是某銀行重要的大型管理系統，具有多團隊協作、多專案並行、多技術體系並用、多產品/模組協同、多環境並存、多時點交付等特點，是一個典型的銀行大型IT系統。我們以C系統為試點，基於TFS，設計了從需求管理、任務分配、分支建立、程式碼提交、版本合併、自動化構建釋出到自動化測試的改寫研發全流程的持續整合和交付流水線。開發人員透過全線上操作發起版本釋出申請，將程式碼收集、版本核對、構建釋出等重覆性工作自動化、線上化，提高了版本交付的效率與質量、釋放了人力資源。
圖1 持續整合和交付流水線模型
1. 自動化程式碼靜態掃描
程式碼靜態掃描是控制程式碼質量的重要手段。對於C系統來說，原有的人工觸發全量檢查方式是一種被動的事後檢查策略，在釋出生產環境前檢查，每次檢查至少需要3個小時，且需要人工甄別增量違例，時效性差、工作效率低、修改成本高等問題突出。
為解決上述問題，我們深入研究了TFS API和JTest、CChecker等靜態檢查工具，透過檔案雜湊值比對等技術手段，對程式碼合規檢查元件和郵件通知元件進行了深度定製，形成了一套按需增量檢查+定時全量檢查相結合的程式碼合規檢查策略，並能夠向相關負責人精準傳送違例程式碼通知。
表1 程式碼合規檢查呼叫的TFS API串列
我們將程式碼合規性檢查整合到持續整合和交付流水線中，在開發人員申請將程式碼合併到測試版本庫或準生產版本庫時，自動觸發程式碼合規性檢查步驟，並自動解析檢查報告，若存在新增違例，則禁止程式碼合併，並向程式碼提交人傳送郵件通知。
圖2 分支策略中配置的程式碼合規性檢查
圖3 程式碼合規性檢查存在新增違例的日誌資訊
2. 程式碼強制評審
程式碼評審主要包括兩方面內容：一是C系統由多個模組構成，每個模組由不同的開發人員負責，當出現跨模組的程式碼修改時，須由該模組的負責人評審改動內容的準確性；二是系統中存在一些公共配置檔案，這些檔案改動後可能會對整個系統產生影響，須由資深的系統研發人員進行評審。
我們藉助TFS拉取請求中的審閱者功能，設計了滿足C系統特點的程式碼強制評審策略，有效避免了誤審、漏審、甚至不審等弊端。
我們首先在TFS中建立了C系統各模組的開發人員團隊，併在分支策略中配置了各模組對應的程式碼路徑。
圖4 分支策略中配置的模組負責人
當開發人員提交程式碼時，TFS會自動判斷是否存在跨模組的程式碼修改，併在拉取請求的審閱者中自動新增模組負責人作為必須的審核人員，只有透過審核才能進行後續的程式碼合併。
圖5 程式碼合併時的強制程式碼審核
3. 持續整合持續交付
持續整合持續交付是提高研發效率、保證產品質量至關重要的一環，我們編寫了一系列構建元件，透過TFS進行元件編排，完成不同環境的持續整合和交付需求。
圖6 TFS構建中的元件編排
C系統前臺使用java語言開發，以一個完整程式包的形式進行釋出。對於日常的研發，將構建釋出配置為定時樣式，每週一至週五12:00和18:00定時自動構建釋出，滿足日常測試需要。
圖7 定時構建釋出配置
對於時效性強的敏捷類專案，將構建釋出配置為實時樣式，每當有程式碼提交時便觸發構建釋出，測試人員可及時介入，縮短開發測試週期。
圖8 實時構建釋出配置
C系統後臺功能使用c語言開發，執行在AIX平臺，無法直接使用TFS的構建功能，經過一系列的技術攻關，我們藉助Jenkins自主實現了一套c程式構建釋出的方法，解決了TFS Agent不支援AIX平臺的技術難題，統一了C系統前後臺的構建釋出流程，為開發人員提供了簡約一致的使用體驗。
圖9 基於AIX平臺的C程式構建流程
c程式具有相對獨立、依賴關係弱的特點，所以均採用由開發人員自主觸發的實時交易構建釋出樣式，每個開發人員可按需獨立釋出程式，在構建引數中填入待釋出的程式名即可。
圖10 C程式自主構建釋出
4. 自動化測試
版本質量是研發的根本落腳點。我們構建了基於Ant+Junit+Selenium的功能測試框架，將測試流程整合到持續整合和交付流水線，實現了業務測試版本和準生產版本的回歸測試，每日定時執行業務核心流程案例，縮短了版本驗證時間，提升了投產版本的可靠性，有效降低了投產風險。
1. 需求條目化和開發
專案經理從專案的角度，以“專案->模組->功能->任務”結構對需求進行條目化拆分，錄入TFS，由專案組成員完成任務認領。隨後基於各自的任務開展需求分析、設計、開發和測試等工作。
圖11 TFS工作項管理層次
圖12 TFS工作項示例
在TFS中配置開發分支自動編譯，當TFS檢測到新的提交後，獲取程式碼並自動編譯，若編譯失敗，則會自動向程式碼提交人傳送郵件通知。
圖13 TFS開發分支自動編譯配置
2. 測試版本釋出
圖14 測試釋出總體流程
開發人員透過TFS工作項和Git的拉取請求（pull request）功能申請將改動的程式碼合併到測試分支。
圖15 TFS工作項申請Git分支
圖16 TFS建立拉取請求頁面
配置管理員在TFS中對測試分支配置分支策略，主要包括：
Ø 必須使用拉取請求的方式向測試分支提交程式碼
Ø 所有拉取請求都需要經過至少一個人審閱
Ø 所有拉取請求都要關聯工作項
Ø 配置分支合併時觸發的預編譯定義
Ø 配置程式碼審查人員
圖17 TFS分支策略配置頁面
在TFS提交拉取請求後，可以在web頁面檢視拉取請求狀態，包括必須滿足的條件、連結的工作項、審閱者、變更內容等，所有條件滿足後即可完成程式碼合併。
圖18 TFS拉取請求頁面
完成程式碼合併後，會自動觸發TFS中配置的程式自動釋出定義，完成測試環境程式包的部署。
圖19 C3前臺自動部署配置
3. 投產版本釋出
圖20 投產釋出總體流程
在TFS中建立投產團隊，從系統的角度，以“系統->視窗->職能組->投產內容”的邏輯層次管理投產內容。開發人員透過工作項發起投產申請，填寫投產內容並透過TFS檔案庫管理投產檔案。填寫完成後將投產申請指派給配置管理員進行審核。
圖21 TFS投產團隊工作項
配置管理員根據投產日期建立準生產分支
圖22 配置管理員建立的準生產分支
開發人員申請將已完成測試的待投產程式碼合併到準生產分支
圖23 建立合併到準生產分支的拉取請求
拉取請求預編譯、評審等工作與測試釋出流程一致。
完成所有待投產內容到準生產分支的合併後，配置管理員在TFS中建立投產標記（基線），基於該標記觸發準生產版本的自動構建，生成投產包，釋出到準生產環境供開發人員進行投產前的最終驗證，驗證完成後在投產視窗將程式部署到生產環境。
圖24 TFS建立標記頁面
基於TFS的端到端持續整合和交付流水線在C系統中的正式應用實現了研發流程自動化、線上化、可追溯的目的，提高了系統研發效率、保證了研發質量、釋放了人力資源、縮短了產品交付週期，是銀行大型IT系統研發樣式轉型的一個典型實踐。銀行IT系統研發流程的DevOps轉型任重道遠，是一個漸進式的過程，我們會對流水線模型進行持續改進最佳化，不斷適應業務和技術的新需求，探索出一條滿足銀行IT特色的DevOps之路。
