歡迎光臨
每天分享高質量文章

某銀行大型管理系統端到端持續集成和交付實踐

 

背景

傳統的銀行IT系統研發流程從需求提出到產品交付往往具有較長的研發周期,縱觀銀行當下麵臨的市場環境,個人信貸消費升級,資管需求旺盛,普惠金融成為國家戰略,來自銀行同業和互聯網金融的壓力撲面而來,誰先推出符合市場需求的產品誰就占領了先機,對銀行IT研發的快速交付能力提出了新的要求和挑戰。

傳統銀行IT系統研發過程中的弊端主要體現在研發流程不連貫難追溯、人工處理效率低時效差、缺乏有效的代碼審查機制、人力資源浪費等,針對上述問題,我們基於持續集成、持續交付的理念,設計了針對某銀行大型管理系統(下稱C系統)的CI/CD流水線,開發了一系列核心組件,基於TFS (現已改名為 Azure DevOps Server)實現了端到端、線上化、全自動的持續交付。

作者:葛江浩、宋紹磊、王麗敏

供職於中國農業銀行研發中心,從事信貸管理領域系統研發工作,致力於銀行大型IT系統端到端全流程敏捷轉型的研究與實踐。

 

 

  C系統是某銀行重要的大型管理系統,具有多團隊協作、多專案並行、多技術體系並用、多產品/模塊協同、多環境並存、多時點交付等特點,是一個典型的銀行大型IT系統。我們以C系統為試點,基於TFS,設計了從需求管理、任務分配、分支建立、代碼提交、版本合併、自動化構建發佈到自動化測試的改寫研發全流程的持續集成和交付流水線。開發人員通過全線上操作發起版本發佈申請,將代碼收集、版本核對、構建發佈等重覆性工作自動化、線上化,提高了版本交付的效率與質量、釋放了人力資源。

 

1 持續集成和交付流水線模型

 

1. 自動化代碼靜態掃描

代碼靜態掃描是控制代碼質量的重要手段。對於C系統來說,原有的人工觸發全量檢查方式是一種被動的事後檢查策略,在發佈生產環境前檢查,每次檢查至少需要3個小時,且需要人工甄別增量違例,時效性差、工作效率低、修改成本高等問題突出。

為解決上述問題,我們深入研究了TFS APIJTestCChecker等靜態檢查工具,通過檔案哈希值比對等技術手段,對代碼合規檢查組件和郵件通知組件進行了深度定製,形成了一套按需增量檢查+定時全量檢查相結合的代碼合規檢查策略,並能夠向相關負責人精準發送違例代碼通知。

 

1 代碼合規檢查呼叫的TFS API串列

 

我們將代碼合規性檢查集成到持續集成和交付流水線中,在開發人員申請將代碼合併到測試版本庫或準生產版本庫時,自動觸發代碼合規性檢查步驟,並自動解析檢查報告,若存在新增違例,則禁止代碼合併,並向代碼提交人發送郵件通知。

2 分支策略中配置的代碼合規性檢查

 

3 代碼合規性檢查存在新增違例的日誌信息

 

2. 代碼強制評審

代碼評審主要包括兩方面內容:一是C系統由多個模塊構成,每個模塊由不同的開發人員負責,當出現跨模塊的代碼修改時,須由該模塊的負責人評審改動內容的準確性;二是系統中存在一些公共配置檔案,這些檔案改動後可能會對整個系統產生影響,須由資深的系統研發人員進行評審。

我們借助TFS拉取請求中的審閱者功能,設計了滿足C系統特點的代碼強制評審策略,有效避免了誤審、漏審、甚至不審等弊端。

我們首先在TFS中創建了C系統各模塊的開發人員團隊,併在分支策略中配置了各模塊對應的代碼路徑。

 

4 分支策略中配置的模塊負責人

 

當開發人員提交代碼時,TFS會自動判斷是否存在跨模塊的代碼修改,併在拉取請求的審閱者中自動添加模塊負責人作為必須的審核人員,只有通過審核才能進行後續的代碼合併。

 

5 代碼合併時的強制代碼審核

 

3. 持續集成持續交付

持續集成持續交付是提高研發效率、保證產品質量至關重要的一環,我們編寫了一系列構建組件,通過TFS進行組件編排,完成不同環境的持續集成和交付需求。

6 TFS構建中的組件編排

 

C系統前臺使用java語言開發,以一個完整程式包的形式進行發佈。對於日常的研發,將構建發佈配置為定時樣式,每周一至周五12:0018: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之路。

    赞(0)

    分享創造快樂