持續集成在商業銀行的實踐探索

【摘要】在完善銀行信息體系的建設中，如何將專業的信息技術和工具與銀行的實際相結合，成為當前銀行業關注的重點。本文在對商業銀行軟件研發現狀及持續集成相關概念進行分析的基礎上，對商業銀行應用持續集成的實踐進行了研究探索，詳細討論了持續集成在商業銀行軟件研發過程中所發揮的積極作用。

【關鍵詞】持續集成 商業銀行 實踐

隨著國內銀行體系的日益開放和監管要求的日益加強，我國銀行信息體系的內部建設也在經歷著巨大的轉變。經過20年的高速發展，我國銀行科技部門及各業務部門的現代信息技術的知識和管理水平得到了快速積累和提高，信息風險防控能力、IT治理能力及軟件研發能力等方面都取得了長足進步和發展。但是，在完善銀行信息體系的建設中，如何將專業度頗高的信息技術和工具與銀行的實際相結合，成為當前銀行業關注的重點。

近年來，商業銀行的業務規模取得了長足發展，軟件研發的數量和規模不斷增長，軟件集成的復雜度和頻度也不斷提升。各商業銀行通過將持續集成應用到軟件研發的實踐過程中，切實在提高軟件資產安全、降低項目研發風險、提高軟件產品質量、提升研發效率等方面發揮了重要作用。

一、商業銀行軟件研發現狀

當前，國內商業銀行業務應用系統規模龐大、功能繁多、需求變更頻繁，采用傳統瀑布模型的開發和管理模式運作的項目組在項目研發過程中遇到很多影響軟件質量與管理效力的問題：

（一）工具種類繁多，未實施有效集成

為提高信息科技的基礎管理能力，商業銀行陸續采購了配置管理、變更管理、缺陷管理和測試管理工具等涉及軟件研發生命周期不同階段的管理工具，工具不僅種類多而且工具之間缺乏有效的集成，數據無法有效共享。比如，配置管理工具的代碼變更集未同缺陷管理工具的缺陷實例進行關聯，無法方便、及時地獲取代碼變更集和需修復缺陷的對應關系。

（二）手工操作繁瑣，自動化程度低

在商業銀行軟件開發過程中，大量地開發和管理類活動均采用手動過程，不僅降低了整個開發團隊的工作效率，而且增加了引入人為失誤的風險，重復執行也浪費了大量人力，使得發現、解決問題變得異常困難。比如測試人員在測試環境中所發現的問題，可能是由于部署人員忘記拷貝了某個配置文件，也可能是由于沒有刪除某些臨時文件。

（三）集成構建較晚，無法有效控制產品交付時間

商業銀行應用系統的架構一般分為前、中、后臺三層。一個項目往往由一個主辦方和多個協辦方統一協調完成，應用系統之間的耦合度越來越緊密。同一系統的不同層級之間或不同應用系統之間的集成構建往往到了產品發布前的最終集成時才剛剛開始，使得“從代碼到編譯集成”以及“從編譯集成到可交付軟件”2個過程的時間長短無法有效控制。比如一般解決編譯甚至測試出現十幾個問題，可能會耗費團隊一天的時間來修補出現的錯誤。但是，如果到一個月以后的集成構建才發現這些問題，這些問題可能會出現數十個，有時可能會出現近百個錯誤，這可能會花費團隊兩到三天時間進行修補，構建越不頻繁，變化的堆積也就越多，開發部門應對這些變化的所花費的時間也就越長。

為解決上述問題，進一步提高軟件的產品質量和產品研發的工作效率、保證軟件系統處于一個穩定可控的狀態，商業銀行紛紛引入了持續集成的理念，并和已有管理工具有效融合。

二、持續集成的方法論

在一個人開發的項目中，依賴外部系統比較少的情況下，軟件集成不會成為太大的問題，但是隨著項目復雜度的增加，就會對集成和確保軟件組件能夠一起工作提出更多的要求——要早集成、常集成。等到項目快結束時才來集成會導致各種各樣的軟件質量問題，解決這些問題代價很大，常常會導致項目延期。持續集成以較小增量的方式迅速解決這些風險。

（一）持續集成的概念

大師Martin Fowler對持續集成是這樣定義的： 持續集成是一種軟件開發實踐，是現代軟件開發的必備配置。在持續集成過程中，團隊成員可以頻繁集成他們的工作成果，每次集成會經過自動構建的驗證，從而盡快地檢測出集成的錯誤。

（二）持續集成的特征

1.源代碼編譯。持續的源代碼編譯是持續集成最基本、最常見的特征。編譯指的是將開發人員編寫的源代碼生成可執行的代碼。

2.測試。沒有自動化、持續測試的持續集成不能算是真正的持續集成。沒有自動化的測試，開發人員或其他項目風險承擔者對軟件的變更很難有信心。

3.審查。自動化的代碼審查（包括靜態和動態分析）可以通過強制遵守規則來提高軟件的質量。

4.部署。持續部署可以在任何時候都可以拿出能工作的、可部署的軟件。

5.反饋。持續集成的本質是及時向開發人員和項目風險承擔這提供反饋信息。

（三）持續集成的實施要素

持續集成是一個以人為核心的過程，常常與一個或多個工具相關聯，但持續集成遠不只是個工具。實施持續集成需要五個要素：

1.開發人員。當一名開發者根據分配的任務進行了所有的修改之后，他將執行一次私有構建，然后將變更提交到版本控制庫。只有當這些變更提交到版本控制庫后，才會開始后續的集成構建。

2.版本控制庫。版本控制庫的目的是通過一個受控的訪問庫來管理源代碼和其他軟件資產的變更。提供一個“單一源代碼位置”，這樣所有的代碼都可以從一個權威的位置獲得。同時本版控制庫能夠進行回溯，取到源代碼和其他文件的不同版本。

3.持續集成服務器。持續集成服務器在變更提交版本控制庫之后執行集成構建。集成構建可以采用手工、定時和輪詢的方式進行。

4.自動構建。持續集成過程會經常集成軟件，這需要通過構建來完成。通過使用自動化構建腳本可以可靠地自動執行編譯、測試等任務，甚至可以執行代碼檢查和部署。構建策略是成功的持續集成過程最重要的方面，如果缺少適當的構建過程，持續集成就難以發揮作用。

5.反饋機制。持續集成的一個關鍵目標是提供集成構建的反饋信息。反饋機制包括郵件、短信息，即時通訊等方式。

三、持續集成在商業銀行的實踐

近幾年，國內商業銀行為提高風險防控能力，適應互聯網金融的發展需要，快速響應銀行客戶的需求，紛紛引入了持續集成來降低產品研發風險、縮短產品研發周期，并解決軟件研發過程中出現的問題。

（一）持續集成的流程

商業銀行的持續集成流程一般都以自動化為基礎，以配置管理為核心，通過將配置管理、變更管理和構建管理工具有效集成，實現了代碼下載、編譯打包、發布部署等功能的標準化、流程化、工具化、自動化，盡早而頻繁地構建以盡早發現系統問題、保證系統的正確性。其流程如圖所示：

持續集成的工作流程為：

第一，通過集成變更管理與配置管理工具，實現需求變更（缺陷）與代碼變更集的對應關系。以需求變更（缺陷）為基礎能查詢到修改的代碼，以變更集為基礎查詢到對應的需求變更（缺陷）。

第二，對已經完成代碼修改的需求變更（缺陷），查詢到對應的變更集，將變更集從開發分支歸并到測試分支，在測試分支創建全量標記。

第三，將測試分支全量代碼下載到集統一編譯服務器。

第四，利用構建腳本實現代碼的自動化編譯和創建程序包。

第五，利用集成的代碼檢查工具，實現自動化的代碼檢查并發布代碼檢查報告。

第六，利用FTP將程序包發布并部署到測試服務器，并執行自動化測試，同時發布測試報告。

持續集成流程涉及的人員角色分別為：

需求或測試人員：針對測試中發現的問題在變更（需求、缺陷、工作任務）管理工具中進行登記。

項目經理：在變更管理工具中將工作分配給具體的開發人員。

開發人員：接受開發任務，在配置管理工具的開發分支建立變更集，同時將變更集和變更管理工具中的任務進行關聯。在開發完成后，在本地機器執行完一次私有構建后，將修改后的代碼以變更集的形式提交到配置管理服務器。

構建管理員：手動啟動持續集成運行流程，并維護相關的配置信息。

業務測試人員：對已完成部署的軟件進行測試，并在變更管理工具中填報測試結果。

代碼審查人員：查看持續集成服務器自動發送的代碼審查報告。

持續集成服務器可以快速地反饋構建過程中的問題，同時也要求項目組對引起構建失敗的原因盡快處理，以保障后續階段的順利進行。

（二）持續集成的主要功能

持續測試：自動化測試提供對單元測試和集成測試的支持，通過調用自動化測試工具生成測試報告。如有需要，還能給出代碼覆蓋度分析報告。

持續構建：實現對代碼的自動化下載、編譯和打包。

持續評審：基于配置庫中的代碼進行代碼規范性檢查，檢查內容包括商業制定的JAVA編碼規范。

持續部署：將構建工作的輸出持續部署到目標測試環境，并利用自動化部署腳本完成產品部署工作。

持續反饋：通過各種渠道將上述持續性工作的具體結果分發出去，包括郵件、FTP等方式。

四、持續集成的積極作用

從技術角度來看，持續集成幫助商業銀行軟件研發團隊更高效地工作。這些團隊有些是跨部門的，有些是在地理上分散的。持續集成解決了許多傳統模式下研發團隊都經歷過的早期陷阱，使更多人可以利用敏捷研發模式，并讓敏捷方法更高效地工作。

從業務的角度來看，持續集成又幫助商業銀行提供了更好的業務成果。通過實施持續集成，在問題的早期并且還是小問題時發現它們，而不是等到這些問題變成大問題且更難解決時才發現它們，實現了商業銀行將產品更快地推向市場。同時還在產品開發過程中更快速地響應市場需求，為未來的互聯網金融打下了堅實的基礎。

（一）降低軟件研發風險

1.隨時隨地生成可部署的軟件。從客戶和用戶的角度看，一個可以部署或執行的構建產物才是最重要的。在使用持續集成工具的環境中，開發人員對源文件進行修改、提交，持續集成服務器會將這部分修改與其他的代碼進行整合、測試，并重新生成最終產品。如果其中任何一個環節出現了問題，相關人員可以很快得到反饋。在沒有使用持續集成工具的環境中，大量的問題只有在產品發布前進行最終集成時才會發現，開發團隊往往在發布前承受著巨大的壓力，并有可能導致產品延遲發布或者在進行Hotfix（修補程序）的過程中引入更多、更嚴重的缺陷。

2.盡早發現軟件缺陷。持續集成的過程可以幫助開發人員快速發現并解決問題。與開發人員的機器相比，持續集成服務器運行在相對穩定、干凈的環境中（可減小跟蹤調試的難度）。持續集成過程的失敗，通常意味著最近一次更新破壞了軟件現有功能或引入了新的缺陷。在持續集成過程結束后，除了構建結果，通常會生成代碼分析報告，幫助項目管理人員更好地了解并改善項目。

3.提高軟件產品質量。持續集成過程要求開發或測試人員事先編寫好很多的測試用例，在代碼提交后就對代碼進行測試，這樣的盡早測試能夠最快速地發現軟件代碼中的錯誤和缺陷，及時修改，從而提高軟件的質量。在項目研發過程中，編寫測試用例都至少會額外增加30%的工作量。初看，這些工作增加了工作量，在時間和資金上是很大的開銷。然而，在商業銀行實施持續集成過程中，要求每個項目必須有明確的測試報告，因此編寫測試用例是必要的，而且這樣也省去了人工測試的時間，確保了軟件產品的質量，有利于提高商業銀行軟件產品的質量管理。

（二）轉變軟件研發理念

持續集成的理念是持續集成的靈魂。持續集成的實施不僅是持續集成平臺的搭建，更是一個系統性工程，涉及開發理念、測試理念和管理理念的轉變。

開發理念的轉變。開發人員針對每個變更（需求、缺陷）編寫代碼，代碼提交后觸發自動化構建、代碼檢查和部署測試等。該流程使得開發人員意識到不僅需要編寫功能實現的代碼，還要確保提交的代碼不會造成其他成員的代碼構建失敗。

測試理念的轉變。在開發人員編碼時，測試人員要同步編寫相對應的測試用例并對已開發功能進行測試，需求人員、開發人員和測試人員組成小團隊以并行迭代方式協同工作。

管理理念的轉變。持續集成反映了系統開發的真實進度和質量，管理人員從關注計劃和文檔向關注持續集成的結果轉變。應管理和效率并重，持續集成只是管理的一種手段。

要讓所有的干系人接受持續集成的理念，商業銀行采取了從易到難、逐步推進的方式，從自動化編譯開始到自動化代碼審查，再到自動化測試，逐步地讓項目組成員認識與接受，最終實現整體的自動化。

（三）加強團隊之間溝通

軟件開發本身就是一項強調溝通和協作的活動，持續集成以制度的形式加強了商業銀行不同部門成員之間溝通和協作，因為每一次的構建都會涉及到項目軟件團隊中的所有成員，“每一次構建的成功，是整個團隊的成功；而每一次構建的失敗，也將是整個團隊的失敗”，因而所有成員的最終目標都是朝著每次的成功構建努力。

（四）增強安全感

軟件開發過程最終表現為人與人之間各種形式的合作，安全感與信心是合作中最基礎也是最重要的。通過使用持續集成工具，開發人員可以了解到新的代碼是否引入了缺陷，管理人員可以通過使用各種形式的報告對項目進行評估。不斷發布的構建結果，使測試人員得以自始至終地參與到整個開發過程中，而不是在軟件開發的最后階段才加入團隊。

五、實踐總結

持續集成不僅是一種軟件研發技術上的實現，也是一種管理制度的實現，需要整個團隊的密切配合才能實現。商業銀行大多在歷經現狀調研、試點驗收、實施推廣等工作后.最終實現了持續集成在軟件研發過程中的順利實施，并達到了預期的結果，為商業銀行信息化的發展開啟了全新一頁。

參考文獻

[1]陳剛，羌鈴鈴.持續集成在項目中的分析與研究，電腦編程技巧與維護，2011（24）：12-15.

[2]黃永剛，王斯洋.持續集成方法在項目中的應用實踐.中國金融電腦，2008（8）.

[3]王英.持續集成在軟件項目管理中的作用.福建電腦，2009 （12）.

作者簡介：孫紹偉（1981-），男，漢族，北京人，供職于中國農業銀行軟件開發中心，研究方向：金融信息技術；李明（1971-），女，漢族，北京人，供職于中國農業銀行軟件開發中心，研究方向：金融信息技術；蘇小彥（1982-），女，漢族，河北廊坊人，供職于中國農業銀行軟件開發中心，研究方向：金融信息技術；姚元慶（1977-），男，漢族，遼寧凌海人，供職于中國農業銀行軟件開發中心，研究方向：金融信息技術。