銀行持續(xù)交付實戰(zhàn):一個單體系統(tǒng)足以撐起全球大項目
來自:DBAplus社群
作者介紹
劉華(Kenneth),就職于世界500強銀行,負責基金服務業(yè)務軟件開發(fā)與交付,DevOps團隊負責人。敏捷、精益、DevOps領域?qū)<遥O限編程、Scrum、看板方法、測試驅(qū)動開發(fā)、持續(xù)集成、行為驅(qū)動開發(fā)、DevOps工具棧。著有《獵豹行動:硝煙中的敏捷轉(zhuǎn)型之旅》一書。
我們的核心系統(tǒng)是一個單體系統(tǒng),支撐全球多個國家和地區(qū)的業(yè)務。同時,業(yè)務部門近年生意紅火,接了幾個大客戶,針對這些大客戶的大型項目也在如火如荼地進行中。
由于生產(chǎn)環(huán)境只有一套,而且已經(jīng)有業(yè)務在生產(chǎn)環(huán)境上跑,這些大項目最終也要在這套生產(chǎn)環(huán)境上上線。這套系統(tǒng)是糅合了各地、各不同業(yè)務的復雜系統(tǒng)。
之前,為了滿足各個客戶交付時間,每個項目都拉了一個獨立的分支進行開發(fā),減少各項目之間的依賴,但這也導致了每個項目各自為政,互不交流。一旦這些項目開發(fā)完成,要和生產(chǎn)環(huán)境的版本進行合并。這種巨型合并勢必帶來巨大風險,相互隔絕的開發(fā)模式也將帶來大量的合并沖突。
我們一直在思考如何降低這種合并風險,以及如何打破各大型項目各自為政的困局,實現(xiàn)產(chǎn)品化的敏捷交付?;貧w測試成為實現(xiàn)這些使命的基礎。
使命——實現(xiàn)敏捷交付
前面提到,目前的開發(fā)模式是針對不同的大客戶,分別設立了不同的大型項目進行開發(fā)。這些項目的交付周期往往數(shù)以年計,交付周期長,風險大。
生產(chǎn)環(huán)境又只有一套,而且已經(jīng)有業(yè)務在生產(chǎn)環(huán)境上跑,代碼合并困難,上線風險巨大。
我們希望能打破這種大型項目的交付形式,以產(chǎn)品化的思維進行管理。
具體實施的思路是:
合并——對各大型項目的現(xiàn)有代碼與生產(chǎn)環(huán)境的版本進行一次性的合并;
統(tǒng)一Backlog——各類需求(包括現(xiàn)在以大型項目形式服務的大客戶的需求)以用戶故事的形式進入到同一個Backlog;
Scrum——建立以Scrum為形式的持續(xù)交付機制,以一個月作為Sprint的周期,通過Sprint計劃會議敲定Sprint的交付計劃;
持續(xù)交付——每個Sprint完成計劃內(nèi)各用戶故事的交付全流程,包括回歸測試和上線到生產(chǎn)環(huán)境。
要實現(xiàn)以上模式,上線前的回歸測試至關重要。而且由于一個Sprint內(nèi),也就是一個月內(nèi),要完成Sprint交付計劃內(nèi)所有用戶故事的需求澄清、設計、開發(fā)、測試、用戶驗收和上線,時間非常緊,回歸測試也必須在一、兩天內(nèi)完成。
如何實現(xiàn)既能充分保護生產(chǎn)環(huán)境,又能實現(xiàn)快速反饋的回歸測試,成為一個重要議題。
自動化大量功能測試不可行
對于如何設計和實施覆蓋率高、執(zhí)行穩(wěn)定而且快速的自動化回歸測試,一直是一個難題。
我們曾經(jīng)的一個思路是把現(xiàn)有的功能測試用例進行自動化,但很快發(fā)現(xiàn)這個思路不可行,主要原因如下:
只能依賴UI測試——由于核心系統(tǒng)是供應商產(chǎn)品,開發(fā)是由供應商負責的,對我們來說就是個黑盒子,我們只能通過UI進行測試。眾所周知,UI的自動化測試,開發(fā)、維護成本高,脆弱而且執(zhí)行時間長;
無法快速反饋——通過功能進行覆蓋,要求不斷增加測試用例來提高覆蓋率,由于UI測試的執(zhí)行時間長,用例越多,整體執(zhí)行時間越長,如果執(zhí)行周期要數(shù)以天計,則無法達到快速反饋的目的;
性價比低——功能測試用例的覆蓋率其實是不可見的,即使把所有功能測試都自動化了,其實際覆蓋率依然不高,也就是說這個投入的性價比很低。
我們必須要尋找一種方法,以最小的投入獲取最大的保障。
我們對回歸測試自動化的預期進行了重新定位。我們進行回歸測試,就是要保護生產(chǎn)環(huán)境的關鍵業(yè)務可以照常進行。我們要防止的,是新的特性發(fā)布造成生產(chǎn)環(huán)境災難,也就是導致關鍵業(yè)務無法進行的大面積故障。對于非災難性的小故障,完全可以通過運維手段來處理。
因此,我們不應該把回歸測試定位為防止一切問題。
以不變應萬變
基于以上對回歸測試預期的重新定位,我們和業(yè)務部門協(xié)商,請他們列舉出當前在生產(chǎn)環(huán)境上最關鍵的業(yè)務過程有哪些。我們要保證的是,當新的特性上線后的首個交易日,原有的最關鍵的業(yè)務過程不會受到嚴重影響。
基于這個預期,我們以業(yè)務部門提供的關鍵業(yè)務過程作為測試用例,并形成以下的回歸測試思路:
準備階段:
在某個測試環(huán)境里,系統(tǒng)版本與生產(chǎn)環(huán)境版本相同;
備份環(huán)境數(shù)據(jù);
以某個交易日為基準,執(zhí)行相應的測試用例;
備份輸入、輸出數(shù)據(jù)(包括生成的接口文件和報表)。
執(zhí)行階段:
在該測試環(huán)境里,導入在準備階段備份的環(huán)境數(shù)據(jù);
升級系統(tǒng)到目標版本;
以準備階段相同的交易日和相同的輸入數(shù)據(jù)(在準備階段已備份)執(zhí)行相同的測試用例,生成相應的接口文件和報表;
與準備階段的輸出(接口文件和報表)進行比對;
如果目標版本的輸出與原版本的對比沒有非預期的差異,視為通過。
簡單總結,就是對比兩個系統(tǒng)版本在相同測試環(huán)境、相同環(huán)境數(shù)據(jù)、相同交易日、相同輸入的情況下,輸出是否有非預期的差異。
這個思路的最大特點是,以不變應萬變。生產(chǎn)環(huán)境的關鍵業(yè)務過程不會經(jīng)常變化,也就是說測試用例基本上比較固定。通過反復運行固定的測試用例實現(xiàn)回歸測試的目標,保護生產(chǎn)環(huán)境上的關鍵業(yè)務過程,避免災難。以最少的用例實現(xiàn)最大的保護。
而且測試的結果驗證是通過比對不同版本的輸出,我們不必在乎具體的輸出內(nèi)容,只需要關注輸出是否有非預期差異。
當然,一旦有新的大客戶上線,也就是有新的關鍵業(yè)務過程,這些過程也應該放入到回歸測試用例中,當然,用例的選擇還是以避免災難為準則。
在前面提到的功能測試思路里,我們需要不斷增加測試用例以增加測試覆蓋率,但是由于測試只能在UI進行,這樣無限增加功能測試用例是不可持續(xù)的。
通過實踐,我們發(fā)現(xiàn)要充分發(fā)揮這個新思路的價值,要注意以下幾點:
專屬環(huán)境——由于這套環(huán)境需要反復整理環(huán)境數(shù)據(jù)和升級,一定要為這個回歸測試準備一套專屬的測試環(huán)境,不要在共享的環(huán)境里進行;
明確檢查點——由于執(zhí)行測試輸出的接口文件、報表里一定有時間戳、自增ID等每次執(zhí)行都會變化的信息,不能簡單通過文件來比對。在擬定測試用例時,就應該明確這些接口文件、報表里的有哪些數(shù)據(jù)需要檢查。在每個版本交付時,開發(fā)人員也應該明確告知哪些數(shù)據(jù)檢查點會有預期差異。否則對比工作將耗費大量的時間和精力;
變更范圍要小——如果對比的兩個系統(tǒng)版本的變更范圍太大,會導致輸出有大量差異,比對意義不大。因此這個方法不太適合大的合并,比較適合落實了敏捷交付后,由于每個Sprint的變更范圍較小,兩個系統(tǒng)版本間的輸出差異不多,比對較容易。
以這個思路建立了回歸測試框架,我們便可以著手執(zhí)行過程的自動化,從而提升其執(zhí)行的效率。
總結
我們的核心系統(tǒng)是一套單體復雜系統(tǒng),支撐全球多個國家和地區(qū)不同的業(yè)務。
為了實現(xiàn)敏捷交付,我們希望打破目前以大型項目為形式的各自為政,把各項目的所有需求放在統(tǒng)一的Backlog通過Scrum的方法進行持續(xù)交付。
要實現(xiàn)這一點,我們需要在每個Sprint都進行有效的回歸測試,以保護生產(chǎn)環(huán)境的關鍵業(yè)務在新特性上線后不會有災難性的故障。
通過對比兩個系統(tǒng)版本在相同測試環(huán)境、相同環(huán)境數(shù)據(jù)、相同交易日、相同輸入的情況下,執(zhí)行關鍵業(yè)務過程的有限的測試用例,輸出是否有非預期的差異的回歸測試方法,以少勝多,以不變應萬變,持續(xù)保護生產(chǎn)環(huán)境的核心業(yè)務,為持續(xù)交付保駕護航。
特別推薦一個分享架構+算法的優(yōu)質(zhì)內(nèi)容,還沒關注的小伙伴,可以長按關注一下:
長按訂閱更多精彩▼
如有收獲,點個在看,誠摯感謝
免責聲明:本文內(nèi)容由21ic獲得授權后發(fā)布,版權歸原作者所有,本平臺僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!