背景

傳統的銀行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之路。

微軟DevOps技術社區持續招募中

我們的DevOps社區仍然繼續招募中，希望加入的小伙伴可以掃描下面的【DevOps社區運營助手】二維碼添加好友并申請入群。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的某银行大型管理系统端到端持续集成和交付实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。