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

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

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

以上簡(jiǎn)單交代了DevOps的作用，下面詳細(xì)講述一個(gè)筆者經(jīng)歷過(guò)的DevOps實(shí)踐案例。

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

由于歷史原因，環(huán)境也存在差異，部分項(xiàng)目有SIT、UAT，部分項(xiàng)目只有SIT。制品提交生產(chǎn)的過(guò)程由各個(gè)項(xiàng)目組負(fù)責(zé)，不統(tǒng)一、標(biāo)準(zhǔn)化難落地?？梢哉f(shuō)國(guó)內(nèi)大多數(shù)大中型企業(yè)都有類似情況。

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

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

拉取代碼>>編譯打包>>部署SIT>>通知SIT測(cè)試>>部署UAT>>通知UAT測(cè)試 >>提升生產(chǎn)

實(shí)施前：每個(gè)項(xiàng)目需要一個(gè)專人，一次交付大約需要3小時(shí)，如果出現(xiàn)錯(cuò)誤，大約0.5-1天不等，人為誤操作無(wú)法避免，規(guī)范、標(biāo)準(zhǔn)難落地。

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

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

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

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

持續(xù)交付（Continuous delivery）指的是，頻繁地將軟件的新版本，交付給質(zhì)量團(tuán)隊(duì)或者用戶，以供評(píng)審。如果評(píng)審?fù)ㄟ^(guò)，制品（也就是常說(shuō)的程序包）就進(jìn)入生產(chǎn)階段。

看下圖勝過(guò)千言萬(wàn)語(yǔ)：

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

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

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

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

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

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

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

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

例如：研發(fā)中心運(yùn)維項(xiàng)目組—NPM技術(shù)—SIT測(cè)試—V1.0

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

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

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

如是配置應(yīng)用已分離的情況，只會(huì)編譯出來(lái)一個(gè)制品，流水線的制品整體生命周期就只會(huì)針對(duì)該制品進(jìn)行流轉(zhuǎn)，當(dāng)開發(fā)人員、測(cè)試人員完成之后，制品會(huì)相應(yīng)提升至預(yù)發(fā)布庫(kù)。

制品在提升到預(yù)發(fā)庫(kù)時(shí)，項(xiàng)目經(jīng)理會(huì)針對(duì)這次上線進(jìn)行質(zhì)量關(guān)卡的把關(guān)，同時(shí)會(huì)將此次制品全生命周期涉及到部署次數(shù)、構(gòu)建信息、測(cè)試信息、質(zhì)量代碼等信息，收集到一起，作為上線發(fā)布的依據(jù)，如果項(xiàng)目經(jīng)理?yè)?dān)心制品流轉(zhuǎn)出錯(cuò)，還可以通過(guò)MD5進(jìn)行比對(duì)，按照如下流程：

例如用sit制品與提交生產(chǎn)的prod制品比對(duì)，對(duì)比文件差異如下圖：

查看詳細(xì)的差異：

三、線上跨團(tuán)隊(duì)交互，記錄交互節(jié)點(diǎn)信息

如下圖，先看看跨團(tuán)交互節(jié)點(diǎn)：

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

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

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

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

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

大家可能會(huì)想，這就是一個(gè)簡(jiǎn)單的通知功能，能有多大作用？別小看了，效果有兩個(gè)：

以上是我們持續(xù)交付的經(jīng)驗(yàn)分享，持續(xù)交付方式多種多樣，能解決客戶痛點(diǎn)，提升效率與質(zhì)量，減少交互過(guò)程中的等待時(shí)間就是好辦法。