? 大型金融企业DevOps持续交付实践 - 公司新闻 | 新炬网络
當前位置: 首頁 > 關于新炬 > 新聞資訊 > 正文

大型金融企業DevOps持續交付實踐

2020-07-01 08:49:43

作者介紹


符強,新炬網絡DevOps專家,從事IT行業10余年,擁有豐富的開發、測試、運維工作經驗。現致力于DevOps相關建設與實施推廣的研究,具有多個大型電信、金融企業DevOps項目經驗。
 

DevOps的作用

 

傳統企業級IT產品具有規模大、開發人數多、技術水平相對落后的缺點,每一代產品從源代碼構建、測試到發布的過程都會跨越組織內部多個相對分離的領域,且產品開發完全外包,對產品迭代速度、交付質量有較大影響。因此,需要一種方法和技術:
 
能夠有效縮短提交代碼到正式部署上線的時間,降低風險;
能夠自動地、快速地提供反饋,以便及時發現和修復缺陷;
能夠讓整個交付過程變得可靠、可預期、可視化。
 
\
 
企業引入DevOps理念,努力將支撐系統傳統開發模式和系統運營方式向以業務價值為導向的開發運營融合模式轉型。以平臺形式固化開發運營一體化框架體系的流程,打通從敏捷需求管理、配置管理、個人構建、版本構建、系統測試、上線發布及產品運營的產品全生命周期,實現了產品全流程可視化、評價指標規范化、產品運營可持續化。
 
\
 
提供軟件開發全生命周期管理和流程自動化,逐步解決研發、QA、運維三者之間的矛盾,促進產品需求快速響應、版本快速迭代、流程更清晰、管理可視可控等。
 
以上簡單交代了DevOps的作用,下面詳細講述一個筆者經歷過的DevOps實踐案例。

 

DevOps持續交付實踐

 

客戶背景
 

 

以一家金融企業為背景的案例,該企業有各類項目500+,開發人員1000+。技術棧百花齊放,有JAVA、NPM、Python、Scala、GO等。以JAVA技術為例,有MAVEN、ANT編譯、容器,有微服務、父子工程、傳統技術架構,有配置分離與不分離的差別等。
 
由于歷史原因,環境也存在差異,部分項目有SIT、UAT,部分項目只有SIT。制品提交生產的過程由各個項目組負責,不統一、標準化難落地。可以說國內大多數大中型企業都有類似情況。
 
綜上所述,在集中、統一管理的前提下,如何快速、有效、穩定地給生產提供制品成為了首要目標。

 

實施效果
 

 

先對比一下持續交付實施前后的情況,按客戶要求,一次完整的制品交付應該包括:
 
拉取代碼>>編譯打包>>部署SIT>>通知SIT測試>>部署UAT>>通知UAT測試 >>提升生產
 
實施前:每個項目需要一個專人,一次交付大約需要3小時,如果出現錯誤,大約0.5-1天不等,人為誤操作無法避免,規范、標準難落地。
 
實施后:一鍵觸發無需專人,一次交付大約需要30分鐘,不會有人為誤操作,標準化流水線。單次交付時間能夠減少2.5小時左右,交付效率大約提高6倍。
 
接入各類變更頻繁的項目150+,工程數量800+,管理10000+制品,持續交付流水線已運行70000+次,月均運行超過10000+次,基本實現了快速、有效、穩定地給生產提供制品的目標,當然,我們還在不斷改善中……
 
DevOps是一個較大的概念,持續交付只是一個組成部分。
 
關注持續交付,不同的企業、不同的團隊站在不同的角度存在不同的定義。本文只是從軟件研發的技術角度進行定義:
 
持續交付(Continuous delivery)指的是,頻繁地將軟件的新版本,交付給質量團隊或者用戶,以供評審。如果評審通過,制品(也就是常說的程序包)就進入生產階段。
 
看下圖勝過千言萬語:

 

\

 

實施持續交付前的問題
 

 

客戶在做持續交付前遇到的主要問題如下:
 
1、缺乏統一標準,各個項目組自行交付,需要熟悉本項目情況的專人負責,專人不在就影響交付;
 
2、交付規范難落地、難監管,例如程序包變更不通過編譯打包,而是手工替換變更文件;變更后不再經過測試評審等等,常有發生;
 
3、測試程序包與生產程序包代碼來源不一致,導致問題流向生產;
 
4、程序包沒有按照標準目錄存放,或者版本號錯誤,導致生產拿錯了程序包;
 
5、跨團隊交互效率低,例如開發團隊、測試團隊、驗收團隊相互通知不及時等。
 
當然還有其他問題,篇幅原因就不一一羅列了。

 

持續交付建設思路
 

 

面對各種各樣的問題,在這里跟大家分享幾個主要的持續交付建設思路:
 
一、一次構建打包(Automaktic Delivery):在測試、UAT、生產等環境的流轉過程中,只打包一次,軟件包按順序交付到各個環境,最終發布生產
 
為了讓交付標準能夠落地,不再只是一個Word文檔,我們先控制了交付流水線的源頭,不再像使用開源Jenkins一樣,可以自由創建。對于納入交付標準的交付方式,都會為其創建對應的模板,項目接入后,可以根據自己的情況,選擇不同的模板使用,交付過程只需要一鍵觸發,不再依賴專人實施。
 
基于可選模板的流水線創建的實現技術邏輯如下:
 
\
 
1、創建流水線模板時,會根據環境來定義出模板的歸屬:如sit集成測試環境、uat業務測試環境、sit和uat的聯合測試環境。
 
2、流水線模板以項目工程的編譯構建工具的類型來區分屬性,如maven屬性模板、ant屬性模板。
 
3、用戶可根據實際的軟件上線的場景,定義自己所需的流水線常用節點階段。
 
4、創建流水線時,可以根據環境屬性和構建類型來選擇對應的模板,節省了重復配置流水線的時間。
 
5、在創建流水線時,如果工程的屬性是單制品,生成會是一條流水線;如果工程的屬性是多制品,生成會是兩條流水線;如果工程屬性是應用配置未分離,生成的流水線會是多個編譯命令的場景;如果工程屬性是應用配置分離,生成的流水線會是一個編譯命令的場景。
 
二、 制品存放、流轉規則對操作人員透明
 
持續交付會頻繁地產出制品,但并不是每一個制品都能推給生產,面對成千上萬的制品如何存放才不會導致混亂,如何確保制品從開發到測試、從測試到驗收,最后推給生產的過程是正確的,是需要有一套完備、細致的規則進行約束的。由于這一塊工作繁重且容易出錯,人力管理很難滿足要求,所以在這里分享一下我們的做法。
 
首先是制品存放,從如下四個部分考慮存放規則:
 
1、team:產品或團隊、組織結構名稱作為項目的主要標識符;
2、technology:使用的技術,工具或包的類型,例如maven、npm等;
3、maturity:軟件包生命周期,例如開發、測試和發布階段等;
4、version:版本。
 
例如:研發中心運維項目組—NPM技術—SIT測試—V1。0
 
那么這樣的存放方式可以方便從不同角度快速定位需要的制品。
 
其次,為了保證軟件上線部署準確性,每一個業務版本對應的是正確的制品包,一套自動化制品生命周期管理方法尤為重要,參考下圖:
 
\
 
在研發階段,代碼檢出時,根據工程的屬性,如是應用配置未分離的情況,每次編譯構建的時候,會出來各個環境制品,有多少個環境就有多少個制品,例如:dev(開發環境)的制品、sit(集成測試環境)的制品、uat(業務測試環境)的制品、pre(預生產環境)的制品,這些制品會存放在開發階段的指定制品倉庫中,當開發人員測試通過后,流水線會自動將在開發階段倉庫里的sit制品提升至sit測試的制品倉庫里;當測試人員測試通過后,會將開發階段倉庫里的uat制品提升到uat制品倉庫里;當業務測試人員測試通過后,會將開發階段倉庫里的pre制品提升到預發布庫。
 
如是配置應用已分離的情況,只會編譯出來一個制品,流水線的制品整體生命周期就只會針對該制品進行流轉,當開發人員、測試人員完成之后,制品會相應提升至預發布庫。
 
制品在提升到預發庫時,項目經理會針對這次上線進行質量關卡的把關,同時會將此次制品全生命周期涉及到部署次數、構建信息、測試信息、質量代碼等信息,收集到一起,作為上線發布的依據,如果項目經理擔心制品流轉出錯,還可以通過MD5進行比對,按照如下流程:
 
\
 
例如用sit制品與提交生產的prod制品比對,對比文件差異如下圖:
 
\
 
查看詳細的差異:
 
\
 
三、 線上跨團隊交互,記錄交互節點信息
 
如下圖,先看看跨團交互節點:
\
 
沒錯了,這里交互的節點就是提交測試人員、應用程序包審核、應用程序包提升,以提交測試人員為例,簡單功能描述如下:
 
開發者提交測試人員:開發人員在完成代碼提交、編譯部署流程后,使用提測功能供郵件通知提交測試人員進行測試。
 
開發人員——>提交測試人員——>測試人員
 
測試者提交業務人員:測試人員完成測試后,如果不通過,則線下通知開發人員修復;如果通過,則使用提測功能郵件通知業務人員進行驗收測試。
 
測試人員——>提交業務人員——>業務人員
 
大家可能會想,這就是一個簡單的通知功能,能有多大作用?別小看了,效果有兩個:
 
1、通知的內容涉及需求版本、有多少個制品、測試是否達標等專業信息,自動通知只需要填寫收件人的信息即可,大大降低了對操作人員專業技能的要求;
2、大大縮短了跨團隊協作的碎片等待時間,效率得到提升。
 
以上是我們持續交付的經驗分享,持續交付方式多種多樣,能解決客戶痛點,提升效率與質量,減少交互過程中的等待時間就是好辦法。

上一篇:GBase 8a MPP集群擴容實戰
下一篇:新炬網絡助力中國移動某省公司順利完成核心數據庫云化升級

163网赚网 皇鼎彩票 福彩3D 马云支付宝网赚是真的吗 支付宝网赚是真的吗 67娱乐系统 yy那种网赚真实吗 北京两步彩走势图 极速快三 香港开奖结果2019+开奖结果