在前一篇講Capital One如何成功進(jìn)行DevOps轉(zhuǎn)型的文章中，我提到了他們公司總結(jié)出的DevOps轉(zhuǎn)型目標(biāo)是“Delivery High Quality Working Software Faster”，即更快速地交付高質(zhì)量的可工作系統(tǒng)。

其中的“可工作”是指跨產(chǎn)品線、共享服務(wù)和依賴的第三方，確保系統(tǒng)端到端必須可用。持續(xù)交付和DevOps的難點(diǎn)問(wèn)題之一就在于跨系統(tǒng)，尤其是銀行這類多個(gè)復(fù)雜系統(tǒng)共同協(xié)作的場(chǎng)景下，如何做好系統(tǒng)間的對(duì)齊，如何更有序的發(fā)布版本，是整個(gè)交付過(guò)程中非常關(guān)鍵的環(huán)節(jié)。

今天我們就來(lái)談一下大型復(fù)雜系統(tǒng)中如何發(fā)布管理的模式和技術(shù)。

▌常見(jiàn)的發(fā)布管理模式

常見(jiàn)的發(fā)布管理模式主要有以下幾種：

項(xiàng)目發(fā)布模式

發(fā)布窗口模式

發(fā)布火車模式

持續(xù)交付模式

1 ▏項(xiàng)目發(fā)布模式

一般來(lái)說(shuō)，所謂項(xiàng)目就是指在一定約束條件下（主要是限定資源、限定時(shí)間、限定質(zhì)量），具有特定目標(biāo)的一次性任務(wù)。

目前很多大型企業(yè)的系統(tǒng)開(kāi)發(fā)還是按照項(xiàng)目的模式開(kāi)展，比如有時(shí)分為新建類項(xiàng)目（如新建系統(tǒng)）或延續(xù)性項(xiàng)目（如增強(qiáng)或優(yōu)化系統(tǒng)），每個(gè)項(xiàng)目都需要完成從立項(xiàng)、項(xiàng)目啟動(dòng)、項(xiàng)目實(shí)施到項(xiàng)目驗(yàn)收等一系列較為完整的過(guò)程，實(shí)施流程繁瑣、參與人員眾多、普遍交付周期較長(zhǎng)。

由于事先約定了項(xiàng)目所包含的需求或特性集合，當(dāng)所有需求或特性全部開(kāi)發(fā)完成，并通過(guò)驗(yàn)收測(cè)試后，才能批量進(jìn)行版本發(fā)布。過(guò)程中如果出現(xiàn)需求變更或某些需求交付遇到阻礙，常常會(huì)導(dǎo)致項(xiàng)目的延期發(fā)布。

另外，由于項(xiàng)目大小不一，發(fā)布周期不固定，缺少穩(wěn)定的交付節(jié)奏，加之周期通常較長(zhǎng)，可能導(dǎo)致項(xiàng)目交付的可預(yù)見(jiàn)性較差。

2 ▏發(fā)布窗口模式

發(fā)布窗口是指一個(gè)特定的時(shí)間段，在這個(gè)時(shí)間段內(nèi)一個(gè)或多個(gè)團(tuán)隊(duì)可以發(fā)布產(chǎn)品到生產(chǎn)環(huán)境。

發(fā)布窗口一般選擇系統(tǒng)負(fù)載較低的時(shí)候進(jìn)行，盡管現(xiàn)在大多數(shù)應(yīng)用系統(tǒng)的用戶都希望這些系統(tǒng)能夠提供7*24小時(shí)不間斷的服務(wù)。

在大型企業(yè)中，受到系統(tǒng)復(fù)雜度、研發(fā)流程和風(fēng)險(xiǎn)控制等因素的影響，常常選擇周期跨度較大的發(fā)布窗口，比如每季度一次常規(guī)投產(chǎn)、每個(gè)月一次常規(guī)投產(chǎn)，做的好一些的可以達(dá)到每?jī)芍芤淮纬Ｒ?guī)投產(chǎn)。

發(fā)布窗口模式的優(yōu)點(diǎn)：

對(duì)業(yè)務(wù)部門及用戶：提供了始終如一的發(fā)布節(jié)奏；

對(duì)交付團(tuán)隊(duì)：提供了始終如一的發(fā)布日期目標(biāo)；

發(fā)布窗口模式的缺點(diǎn)：

少量的發(fā)布窗口需要同時(shí)集中處理多個(gè)團(tuán)隊(duì)的發(fā)布需求，發(fā)布風(fēng)險(xiǎn)很高；

不同團(tuán)隊(duì)爭(zhēng)搶有限的發(fā)布窗口，帶來(lái)大量溝通和協(xié)調(diào)成本；

不同系統(tǒng)之間存在相互依賴的情況，需要大量時(shí)間統(tǒng)一規(guī)劃和協(xié)調(diào)；

3 ▏發(fā)布火車模式

發(fā)布火車是指組成復(fù)雜系統(tǒng)的每個(gè)團(tuán)隊(duì)都參與到統(tǒng)一發(fā)布節(jié)奏的“火車”中來(lái)。每列發(fā)布火車采用固定的“發(fā)車”時(shí)間，特性的發(fā)布取決于該特性是否趕上最近的火車發(fā)車時(shí)間。如果某個(gè)團(tuán)隊(duì)錯(cuò)過(guò)了發(fā)布日期，即錯(cuò)過(guò)了這列火車，火車還是會(huì)按時(shí)發(fā)出，這個(gè)團(tuán)隊(duì)可以等待下列火車的到來(lái)。

許多大型企業(yè)都在使用發(fā)布火車的發(fā)布模式，這種模式適用于不同團(tuán)隊(duì)有各自負(fù)責(zé)的子系統(tǒng)或組件，但需要整體進(jìn)行對(duì)齊和集成的場(chǎng)景。發(fā)布火車模式的提出最早是一些大型軟件公司組合不同的軟件產(chǎn)品，但近些年來(lái)SAFe等大規(guī)模敏捷框架的推廣讓發(fā)布火車模式更為流行。

當(dāng)然，同樣是發(fā)布火車，不同場(chǎng)景下的展現(xiàn)形式可能不同。比如有的框架介紹發(fā)布火車一般8~12周完成一個(gè)大型產(chǎn)品的增量發(fā)布，有些企業(yè)實(shí)現(xiàn)的小型發(fā)布火車可以做到1~2周級(jí)別的發(fā)布（也有做的更快的，他們叫做班車模式）。

我們這里僅是從管理模式上和技術(shù)實(shí)現(xiàn)上考慮，發(fā)布火車可以實(shí)現(xiàn)多個(gè)子系統(tǒng)或組件團(tuán)隊(duì)之間的高效協(xié)同，以及發(fā)布包的遞次晉級(jí)，我們討論的是一個(gè)廣義上的概念，具體的發(fā)布周期是可以按需求調(diào)整的。

發(fā)布火車模式的優(yōu)點(diǎn)：

發(fā)布火車讓參與的團(tuán)隊(duì)達(dá)成統(tǒng)一的發(fā)布節(jié)奏；

所有參與的團(tuán)隊(duì)可以有效對(duì)齊該版本的各個(gè)實(shí)施階；

發(fā)布火車可以更有效的協(xié)調(diào)多團(tuán)隊(duì)的發(fā)布；

火車的間隔周期通常可以設(shè)置的相對(duì)較短，即便錯(cuò)過(guò)一列火車還可以等待下一列，緩解了爭(zhēng)搶發(fā)布窗口的問(wèn)題；

發(fā)布火車模式的缺點(diǎn)：

統(tǒng)一的發(fā)布火車時(shí)刻表同時(shí)也約束了開(kāi)發(fā)團(tuán)隊(duì)，沒(méi)有做到持續(xù)交付；

如果發(fā)布火車間隔時(shí)間設(shè)置的很長(zhǎng)，一樣會(huì)出現(xiàn)集成的瓶頸；

關(guān)于發(fā)布火車模式的具體實(shí)現(xiàn)細(xì)節(jié)方法，下文會(huì)進(jìn)行詳細(xì)介紹。

4 ▏持續(xù)交付模式

持續(xù)交付是DevOps的核心工程實(shí)踐，也是眾多互聯(lián)網(wǎng)公司采用的交付模式。持續(xù)交付的思路是開(kāi)發(fā)以小批量工作在主干上，或者每個(gè)人工作在短Feature分支上，有規(guī)律的合并主干。主干一直保持可部署狀態(tài)，可以做到通過(guò)一鍵式操作的方式在正常業(yè)務(wù)時(shí)段按需發(fā)布。

在流水線上，開(kāi)發(fā)可以得到快速反饋，包括缺陷、性能問(wèn)題、安全問(wèn)題、易用性問(wèn)題等，當(dāng)問(wèn)題被發(fā)現(xiàn)，他們快速修復(fù)，以保證主干一直保持可部署狀態(tài)。關(guān)于持續(xù)交付的實(shí)施框架和細(xì)節(jié)技術(shù)實(shí)踐，我曾經(jīng)做過(guò)多次分享，但這并不是今天討論的重點(diǎn)，所以我們暫不展開(kāi)。

持續(xù)交付可以做到行云流水一般，快速、按需發(fā)布到生產(chǎn)環(huán)境，相當(dāng)于我們的發(fā)布窗口是7*24小時(shí)！以互聯(lián)網(wǎng)為代表的一些高績(jī)效IT公司，通過(guò)持續(xù)交付可以做到每天成千上萬(wàn)次高質(zhì)量的發(fā)布。但是，做到持續(xù)交付需要非常多的技術(shù)實(shí)踐，包括高度自動(dòng)化的流水線，自動(dòng)化構(gòu)建，自動(dòng)化測(cè)試，自動(dòng)化部署，低風(fēng)險(xiǎn)的發(fā)布技術(shù)等等。

在大型復(fù)雜系統(tǒng)中實(shí)現(xiàn)持續(xù)交付，還需要考慮系統(tǒng)之間相互依賴的問(wèn)題。正確的思路應(yīng)該是讓架構(gòu)盡量做到解耦，使得每個(gè)系統(tǒng)能夠獨(dú)立的開(kāi)發(fā)、測(cè)試、部署和發(fā)布，而不依賴其他系統(tǒng)。每個(gè)系統(tǒng)獨(dú)立演進(jìn)的過(guò)程中，可以通過(guò)契約測(cè)試的方式驗(yàn)證相互接口的正確性，同時(shí)還需要實(shí)現(xiàn)服務(wù)提供方的向下兼容以及服務(wù)消費(fèi)方的容錯(cuò)性設(shè)計(jì)。

▌發(fā)布管理模式的綜合應(yīng)用

我的經(jīng)驗(yàn)是很多傳統(tǒng)一些企業(yè)都在使用發(fā)布窗口模式或發(fā)布火車模式，但也都在積極嘗試持續(xù)交付的發(fā)布模式。通常引入敏捷和DevOps的方法和實(shí)踐都會(huì)促進(jìn)發(fā)布頻率的提升和發(fā)布周期的縮短。

那么如何綜合應(yīng)用以上幾種發(fā)布管理模式，取長(zhǎng)補(bǔ)短，即能夠提升單個(gè)系統(tǒng)的發(fā)布效率，又能兼顧系統(tǒng)之間的依賴關(guān)系呢？這個(gè)是我們接下來(lái)要討論的話題。

1 ▏綜合應(yīng)用的策略

我們需要根據(jù)發(fā)布頻率的實(shí)際需求來(lái)選擇和搭配不同的發(fā)布模式。

在上圖中，我們可以看到有不同類型的發(fā)布需求，比如Major Release（可能是產(chǎn)品級(jí)的功能整體升級(jí)），或者Subsystem Release（可能是某個(gè)子系統(tǒng)內(nèi)部的功能優(yōu)化），也有為了滿足特定合規(guī)性需求或解決線上問(wèn)題的緊急修復(fù)等。

不同的發(fā)布需求對(duì)應(yīng)了不同的發(fā)布節(jié)奏。首先我們要按特定的節(jié)奏規(guī)劃產(chǎn)品級(jí)增量發(fā)布，此時(shí)可以應(yīng)用發(fā)布火車的模式；然后是在產(chǎn)品級(jí)增量發(fā)布的中間，規(guī)劃粒度更細(xì)的子系統(tǒng)級(jí)發(fā)布，以及穿插其中不定期的緊急發(fā)布，此時(shí)可以應(yīng)用持續(xù)交付的發(fā)布模式。

所以我們提出的整體策略就是“按節(jié)奏開(kāi)發(fā)，按需進(jìn)行發(fā)布”。按節(jié)奏開(kāi)發(fā)是指以固定的節(jié)奏安排產(chǎn)品級(jí)發(fā)布規(guī)劃，同步和對(duì)齊不同團(tuán)隊(duì)之間工作，主動(dòng)管理風(fēng)險(xiǎn)并限制非預(yù)期的差異；按需進(jìn)行發(fā)布是指構(gòu)成復(fù)雜產(chǎn)品的不同子系統(tǒng)或組件，可以各自按需靈活安排自己的發(fā)布活動(dòng)，只要合理、合規(guī)就可以在任意適合的時(shí)間進(jìn)行發(fā)布。

2 ▏發(fā)布火車的實(shí)現(xiàn)細(xì)節(jié)

發(fā)布火車的實(shí)現(xiàn)細(xì)節(jié)如下圖所示（引用自EXIN DevOps課程的TTT講師 Bart de Best）:

使用發(fā)布火車將發(fā)布包從構(gòu)建狀態(tài)逐步發(fā)布到測(cè)試及生產(chǎn)環(huán)境。

發(fā)布火車傳輸?shù)膬?nèi)容是發(fā)布包，而非代碼（曾經(jīng)遇到有些團(tuán)隊(duì)用發(fā)布火車模式來(lái)傳遞代碼，這種方式問(wèn)題較多，而且不符合持續(xù)交付的單一制品原則）；

只有出示了“車票”，才被允許上火車；

“車票”是指有效的測(cè)試結(jié)果；

在發(fā)布之旅中有很多的“站點(diǎn)”；

“站點(diǎn)”可以理解為不同的環(huán)境（開(kāi)發(fā)環(huán)境、集成測(cè)試環(huán)境、驗(yàn)收測(cè)試環(huán)境、生產(chǎn)環(huán)境）；

每個(gè)站點(diǎn)上特定的“關(guān)卡”，指的是特定環(huán)境上不同級(jí)別的測(cè)試；

火車會(huì)一站接一站的運(yùn)行，從開(kāi)發(fā)到測(cè)試，從測(cè)試到驗(yàn)收，從驗(yàn)收到生產(chǎn)，遞次運(yùn)行；

每列火車有一個(gè)火車司機(jī)，火車司機(jī)就是發(fā)布經(jīng)理；

火車司機(jī)（發(fā)布經(jīng)理）負(fù)責(zé)判斷是否可以上車，除了檢查是否有車票，還要關(guān)注系統(tǒng)間的依賴和沖突；

如果發(fā)布包沒(méi)有趕上這列火車，或者有Bug，將會(huì)被放置在站點(diǎn)上等待；

直到修復(fù)Bug、通過(guò)測(cè)試（取得車票），并且滿足依賴之后，才能通過(guò)關(guān)卡，并搭乘下一列到達(dá)站點(diǎn)火車，奔向下一站；

下圖形象的展示了整個(gè)過(guò)程：

3 ▏發(fā)布模式的支撐技術(shù)

為了做到更快速、更穩(wěn)健的發(fā)布，僅僅引入相關(guān)的方法是不充分的，還需要在自動(dòng)化發(fā)布技術(shù)、架構(gòu)解耦、可部署性、可靠性、快速恢復(fù)能力等方面進(jìn)行建設(shè)。

除此之外，以下技術(shù)實(shí)踐的使用有助于實(shí)現(xiàn)更為靈活的發(fā)布模式：

功能開(kāi)關(guān)

功能開(kāi)關(guān)打開(kāi)或關(guān)閉，可以控制在生產(chǎn)環(huán)境上的功能是否對(duì)最終用戶可見(jiàn)。比如剛才提到的多種發(fā)布節(jié)奏混合的場(chǎng)景下，可能需要采用多分支的模式匹配不同的發(fā)布版本。

使用功能開(kāi)關(guān)的技術(shù)，就可以轉(zhuǎn)變?yōu)橹鞲砷_(kāi)發(fā)模式，并有效規(guī)避并行多分支的問(wèn)題。如下圖所示，Spotify公司在使用發(fā)布火車模式時(shí)，利用功能開(kāi)關(guān)把未完成功能在發(fā)布時(shí)做隱藏處理，這樣可以盡早暴露集成問(wèn)題、最小化對(duì)并行分支的需求，并降低發(fā)布火車模式下分支管理的復(fù)雜度。

金絲雀發(fā)布

在發(fā)布變更到所有用戶之前，可以先發(fā)布到一小部分用戶，降低直接發(fā)布到生產(chǎn)環(huán)境所帶來(lái)的風(fēng)險(xiǎn)。

比如依次發(fā)布變更的功能到10%、20%、50%的用戶，并在每個(gè)節(jié)點(diǎn)驗(yàn)證一段時(shí)間，最后再進(jìn)行全量發(fā)布。在發(fā)布火車模式中，對(duì)生產(chǎn)環(huán)境的發(fā)布可以按金絲雀發(fā)布的模式，拆分為數(shù)個(gè)更小的發(fā)布階段來(lái)控制風(fēng)險(xiǎn)，如下圖所示：

▌總結(jié)

今天我們介紹了幾種常見(jiàn)的發(fā)布管理模式，在不同場(chǎng)景下綜合應(yīng)用這些模式可以在更快速地交付高質(zhì)量的可工作系統(tǒng)。

發(fā)布管理模式的一些核心要點(diǎn)如下：

策略：按節(jié)奏開(kāi)發(fā)，按需進(jìn)行發(fā)布；

可以根據(jù)發(fā)布頻率的實(shí)際需求來(lái)選擇和搭配不同的發(fā)布模式；

發(fā)布火車模式可以更有效的協(xié)調(diào)大型復(fù)雜系統(tǒng)多團(tuán)隊(duì)的發(fā)布；

持續(xù)交付模式實(shí)現(xiàn)更頻繁的發(fā)布，前提是建設(shè)高度的自動(dòng)化能力及復(fù)雜系統(tǒng)間充分的解耦；

發(fā)布火車模式下，傳輸?shù)膬?nèi)容是發(fā)布包，而非代碼。只有出示了“車票”，才被允許上火車。每個(gè)“站點(diǎn)”上設(shè)有特定的“關(guān)卡”，火車按站點(diǎn)遞次運(yùn)行，每個(gè)站點(diǎn)由”火車司機(jī)”負(fù)責(zé)團(tuán)隊(duì)間對(duì)齊的工作；

配合使用功能開(kāi)關(guān)和金絲雀發(fā)布技術(shù)實(shí)踐，可以讓發(fā)布模式更靈活并降低發(fā)布風(fēng)險(xiǎn)。

今天分享的內(nèi)容可能略微復(fù)雜，整理起來(lái)也花費(fèi)了我不少時(shí)間，但最終還是希望能對(duì)你有所幫助！

心動(dòng)不如行動(dòng)，綜合運(yùn)用以上方法與實(shí)踐，讓你的產(chǎn)品發(fā)布能夠像高鐵一樣穩(wěn)定的飛馳吧！

想了解更多IT資訊，請(qǐng)?jiān)L問(wèn)中培偉業(yè)官網(wǎng)：中培偉業(yè)