大型金融企業(yè)DevOps持續(xù)交付實踐

傳統(tǒng)企業(yè)級IT產品具有規(guī)模大、開發(fā)人數多、技術水平相對落后的缺點，每一代產品從源代碼構建、測試到發(fā)布的過程都會跨越組織內部多個相對分離的領域，且產品開發(fā)完全外包，對產品迭代速度、交付質量有較大影響。因此，需要一種方法和技術：

企業(yè)引入DevOps理念，努力將支撐系統(tǒng)傳統(tǒng)開發(fā)模式和系統(tǒng)運營方式向以業(yè)務價值為導向的開發(fā)運營融合模式轉型。以平臺形式固化開發(fā)運營一體化框架體系的流程，打通從敏捷需求管理、配置管理、個人構建、版本構建、系統(tǒng)測試、上線發(fā)布及產品運營的產品全生命周期，實現了產品全流程可視化、評價指標規(guī)范化、產品運營可持續(xù)化。

提供軟件開發(fā)全生命周期管理和流程自動化，逐步解決研發(fā)、QA、運維三者之間的矛盾，促進產品需求快速響應、版本快速迭代、流程更清晰、管理可視可控等。

以上簡單交代了DevOps的作用，下面詳細講述一個筆者經歷過的DevOps實踐案例。

以一家金融企業(yè)為背景的案例，該企業(yè)有各類項目500+，開發(fā)人員1000+。技術棧百花齊放，有JAVA、NPM、Python、Scala、GO等。以JAVA技術為例，有MAVEN、ANT編譯、容器，有微服務、父子工程、傳統(tǒng)技術架構，有配置分離與不分離的差別等。

由于歷史原因，環(huán)境也存在差異，部分項目有SIT、UAT，部分項目只有SIT。制品提交生產的過程由各個項目組負責，不統(tǒng)一、標準化難落地?？梢哉f國內大多數大中型企業(yè)都有類似情況。

綜上所述，在集中、統(tǒng)一管理的前提下，如何快速、有效、穩(wěn)定地給生產提供制品成為了首要目標。

先對比一下持續(xù)交付實施前后的情況，按客戶要求，一次完整的制品交付應該包括：

拉取代碼>>編譯打包>>部署SIT>>通知SIT測試>>部署UAT>>通知UAT測試 >>提升生產

實施前：每個項目需要一個專人，一次交付大約需要3小時，如果出現錯誤，大約0.5-1天不等，人為誤操作無法避免，規(guī)范、標準難落地。

實施后：一鍵觸發(fā)無需專人，一次交付大約需要30分鐘，不會有人為誤操作，標準化流水線。單次交付時間能夠減少2.5小時左右，交付效率大約提高6倍。

接入各類變更頻繁的項目150+，工程數量800+，管理10000+制品，持續(xù)交付流水線已運行70000+次，月均運行超過10000+次，基本實現了快速、有效、穩(wěn)定地給生產提供制品的目標，當然，我們還在不斷改善中……

DevOps是一個較大的概念，持續(xù)交付只是一個組成部分。

關注持續(xù)交付，不同的企業(yè)、不同的團隊站在不同的角度存在不同的定義。本文只是從軟件研發(fā)的技術角度進行定義：

持續(xù)交付（Continuous delivery）指的是，頻繁地將軟件的新版本，交付給質量團隊或者用戶，以供評審。如果評審通過，制品（也就是常說的程序包）就進入生產階段。

看下圖勝過千言萬語：

客戶在做持續(xù)交付前遇到的主要問題如下：

當然還有其他問題，篇幅原因就不一一羅列了。

面對各種各樣的問題，在這里跟大家分享幾個主要的持續(xù)交付建設思路：

為了讓交付標準能夠落地，不再只是一個Word文檔，我們先控制了交付流水線的源頭，不再像使用開源Jenkins一樣，可以自由創(chuàng)建。對于納入交付標準的交付方式，都會為其創(chuàng)建對應的模板，項目接入后，可以根據自己的情況，選擇不同的模板使用，交付過程只需要一鍵觸發(fā)，不再依賴專人實施。

基于可選模板的流水線創(chuàng)建的實現技術邏輯如下：

二、制品存放、流轉規(guī)則對操作人員透明

持續(xù)交付會頻繁地產出制品，但并不是每一個制品都能推給生產，面對成千上萬的制品如何存放才不會導致混亂，如何確保制品從開發(fā)到測試、從測試到驗收，最后推給生產的過程是正確的，是需要有一套完備、細致的規(guī)則進行約束的。由于這一塊工作繁重且容易出錯，人力管理很難滿足要求，所以在這里分享一下我們的做法。

首先是制品存放，從如下四個部分考慮存放規(guī)則：

例如：研發(fā)中心運維項目組—NPM技術—SIT測試—V1.0

那么這樣的存放方式可以方便從不同角度快速定位需要的制品。

其次，為了保證軟件上線部署準確性，每一個業(yè)務版本對應的是正確的制品包，一套自動化制品生命周期管理方法尤為重要，參考下圖：

在研發(fā)階段，代碼檢出時，根據工程的屬性，如是應用配置未分離的情況，每次編譯構建的時候，會出來各個環(huán)境制品，有多少個環(huán)境就有多少個制品，例如：dev（開發(fā)環(huán)境）的制品、sit（集成測試環(huán)境）的制品、uat（業(yè)務測試環(huán)境）的制品、pre（預生產環(huán)境）的制品，這些制品會存放在開發(fā)階段的指定制品倉庫中，當開發(fā)人員測試通過后，流水線會自動將在開發(fā)階段倉庫里的sit制品提升至sit測試的制品倉庫里；當測試人員測試通過后，會將開發(fā)階段倉庫里的uat制品提升到uat制品倉庫里；當業(yè)務測試人員測試通過后，會將開發(fā)階段倉庫里的pre制品提升到預發(fā)布庫。

如是配置應用已分離的情況，只會編譯出來一個制品，流水線的制品整體生命周期就只會針對該制品進行流轉，當開發(fā)人員、測試人員完成之后，制品會相應提升至預發(fā)布庫。

制品在提升到預發(fā)庫時，項目經理會針對這次上線進行質量關卡的把關，同時會將此次制品全生命周期涉及到部署次數、構建信息、測試信息、質量代碼等信息，收集到一起，作為上線發(fā)布的依據，如果項目經理擔心制品流轉出錯，還可以通過MD5進行比對，按照如下流程：

例如用sit制品與提交生產的prod制品比對，對比文件差異如下圖：

查看詳細的差異：

三、線上跨團隊交互，記錄交互節(jié)點信息

如下圖，先看看跨團交互節(jié)點：

沒錯了，這里交互的節(jié)點就是提交測試人員、應用程序包審核、應用程序包提升，以提交測試人員為例，簡單功能描述如下：

開發(fā)者提交測試人員：開發(fā)人員在完成代碼提交、編譯部署流程后，使用提測功能供郵件通知提交測試人員進行測試。

開發(fā)人員——>提交測試人員——>測試人員

測試者提交業(yè)務人員：測試人員完成測試后，如果不通過，則線下通知開發(fā)人員修復；如果通過，則使用提測功能郵件通知業(yè)務人員進行驗收測試。

測試人員——>提交業(yè)務人員——>業(yè)務人員

大家可能會想，這就是一個簡單的通知功能，能有多大作用？別小看了，效果有兩個：

以上是我們持續(xù)交付的經驗分享，持續(xù)交付方式多種多樣，能解決客戶痛點，提升效率與質量，減少交互過程中的等待時間就是好辦法。