大家好，我是來自工行軟件開發中心的龐良，今天和大家交流的題目是在持續交付領域的建設分享。

今天分享的議題分四個方面：首先介紹一下我們在相關系統的建設的歷程，其次介紹我們在工具鏈方面的建設的實踐；然后介紹一下我們如何推動DevOps的變革。最后說明一下我們的整體目標。

第一個議題。工行這個版本體量相對是比較大的，所以我們的版本節奏也分三個類型。首先是季度版本，按每個季度開發測試投產，包括應用，主要是銀行的核心業務系統，還有我們的Z/OS主機核心應用。第二個就是月度版本，這部分主要是針對直接發布的應用，開放平臺分布式系統，還有上云的應用。最后一個是靈活投產的模式，主要是針對快速原型法，以及敏捷迭代這些發展的應用和開發。

為了支持這些不同節奏的版本發布的功能我們也開發了很多系統。在2008年我們開始自主題版本管理系統，后續逐漸研發和開放平臺的版本開放系統，在2012年引進了CC代碼管理工具，2013年開始做持續集成的研究。2014年我們建立了內部的智能運維平臺，2015年開發了一套版本投產一體化、支持自動化部署的系統，在2015年完成了平臺化以及DOCKER版本管理的功能，2016年探索DevOps在我們行應用的場景，2017年是掃描持續交付系統。2018年我們開始了持續交付的建設，并且完成了投產的運行，實現了上云以及傳統版本的納入流水線投產的功能，另外我們也開始引入了業界DevOps的評估，跟業界做了一些對標。

第二部分，關于工具鏈建設的實踐。首先是源代碼的分支管理的模式。我們的分支管理模型分為兩個，首先是傳統的月度版本的分支模型，主要針對并行版本比較多的場景。另外就是靈活閱讀版本分支模型，主要是針對靈活投產的應用。這兩種模式是并存的，傳統的版本分支模型復雜度比較低，但是不夠靈活。月度傳統模式中我們需要配置特定的配置管理員，一旦月度分支版本建立起來，就需要專門的配置管理員管理這個分支，到交付的時間點，這個分支的所有內容基本上要全量做一個交付投產。如果有一些分支沒有完成，或者有問題的話，要單獨的做一些特殊處理，所以這個月度模式是計劃性比較強的模式。第二個就是靈活的特性分支模型，我們不需要配專門的管理員，由開發人員自己管理，開發完以后直接提到測試分支，測試以后再提交到交付分支，如果測試不通過是不允許提交到交付分支的，所以這個交付分支相對來說是比較干凈的，所以在交付的時候直接把分支交付出去就可以了。

下面介紹一下我們對原數據以及數據庫版本管理的方式。以前工行就是以大型機主機為主，所以我們的整體架構是相對比較集中的，我們開發的語言基本都是用COBOL，數據基本上是用DB2，有五千多張表，效率可以接受，按單個程序、單個表的力度來管理。到了分布式的時代，分布式時代效率嚴重受阻，引進開源的產品做了XML方式管理DDL，引入開源，通過持續交付流水線，自動構建、部署、測試、交付，構建時，自動生成數據結構回寫SEAS、審批不通過不能交付，總體原則是不能因為審批耽誤了效率。

下面介紹一下我們的構建和構建云。構建包括了很多內容，有源代碼到目標的轉換，數據結構到DDL的轉換，配置文件到配置中心K—V的轉換。構建是一種依賴管理，MAVEN命令規范化BURDXML掃描，寫入制品庫，標識關聯。構建是統一的入口，應用服務節點模型入口，版本目錄標準化入口。構建是一種管控，引入黑名單開源JAR包，禁止構建；代碼掃描不合規，禁止構建。原來構建分三層結構，改造成最新的微服務架構，把所有構建的模塊進行了服務化的改造，另外把所有部署的時候構建的部署模式改成了容器化，通過容器化方便地進行擴充容。

下面介紹一下我們的持續集成。這也是采用了業界比較典型的流程，包括獲取源代碼和案例、自動化，編譯部署，自動化測試，報警通知，獲取郵件資源，自動化檢查等等，也是采用Jenkins的流程。

下面介紹一下自動部署，這是我們自研的一個核心產品，采用的是WAS—SLAVE、Agent架構，三中心部署，三中心互通，分行、海外連接到數據中心進行操作。自動化部署工具也是跟制品庫和容器鏡像聯動，實現版本預下載，豐富的標準租件，開發團隊可定制部署策略，香港服務器，比如投產前的備份，投產后的策略定制，還有投產失敗以后有一些恢復的操作。部署工具是支持每個應用根據它自己的特色編寫自己的一些投產的策略，比如傳輸的規則、要執行的腳本，都可以在這個平臺里面做一些可視化的拖拽。