基礎(chǔ)要點(diǎn)

發(fā)布內(nèi)容既可以包括各種基礎(chǔ)架構(gòu)、應(yīng)用組件、更新流程與工具，也可以包括文檔與培訓(xùn)。

發(fā)布管理工作通常發(fā)生在部署之前。

在傳統(tǒng)/瀑布環(huán)境中，發(fā)布管理和部署被合并為單個(gè)進(jìn)程。

在Agile/DevOps 環(huán) 境中，軟件和基礎(chǔ)架構(gòu)往往是一些較小的增量部署，因此既可以采用“藍(lán)/綠發(fā)布”，即兩個(gè)鏡像生產(chǎn)環(huán)境同時(shí)供不同類型的用戶使用；也可以采用“功能標(biāo)記”，即新功能被部署到生產(chǎn)環(huán)境中但不全面釋放，僅釋放給單個(gè)用戶或組。

解讀

無(wú)論是新服務(wù)的啟用，還是針對(duì)當(dāng)前服務(wù)的修補(bǔ)，我們都需要在完成了測(cè)試審查、部署計(jì)劃、回滾步驟，這三項(xiàng)前提條件之后，方可通過(guò)觸發(fā)變更流程來(lái)予以正式發(fā)布。

也就是說(shuō)，只有得到了變更管理委員會(huì)的批準(zhǔn)，我們方可進(jìn)行發(fā)布操作。而之所以要走這樣的流程，就是為了在發(fā)布過(guò)程中一旦出現(xiàn)了不可接受的錯(cuò)誤，我們還能及時(shí)地根據(jù)既定的回滾步驟，后退到發(fā)布之前的系統(tǒng)與服務(wù)狀態(tài)。

由此可見(jiàn)，發(fā)布管理的最終目標(biāo)應(yīng)該是：

實(shí)現(xiàn)并達(dá)到了預(yù)定的系統(tǒng)功能與服務(wù)級(jí)別；

更新了相應(yīng)的配置管理數(shù)據(jù)庫(kù)（CMDB）；

保持了系統(tǒng)與服務(wù)的可用性與穩(wěn)定性。

圖3 常規(guī)發(fā)布管理流程

由于發(fā)布往往會(huì)給系統(tǒng)和服務(wù)帶來(lái)更新，那么為了做好與配置相關(guān)的管理工作，我們勢(shì)必需要對(duì)基礎(chǔ)架構(gòu)、應(yīng)用組件、流程與工具、甚至是文檔與培訓(xùn)等方面，做好相應(yīng)的版本號(hào)編制工作。

就發(fā)布的類型而言，業(yè)界一般會(huì)采用三種傳統(tǒng)的發(fā)布方式：

1.增量發(fā)布（Delta Release）

只是對(duì)從最近一次成功發(fā)布以來(lái)的累計(jì)更新部分予以發(fā)布，原有的部分保持不變。

2.全量發(fā)布（Full Release）

將更新部分連同原有不變的部分作為整體組件，發(fā)布到生產(chǎn)環(huán)境中。

包發(fā)布(Package Release)

將一組新的軟件或服務(wù)進(jìn)行打包，然后直接導(dǎo)入既有的生產(chǎn)環(huán)境之中。

如前所述，無(wú)論我們?cè)趯?shí)際操作中采取哪一種發(fā)布方式，都會(huì)涉及到對(duì)于CMDB 進(jìn)行相關(guān)配置項(xiàng)（CI）的簽出（check out）和簽入（check in）的過(guò)程。即：

在執(zhí)行發(fā)布之前，先讀取系統(tǒng)與服務(wù)的當(dāng)前狀態(tài)，并錨定之。

在完成發(fā)布與部署之后，將軟件的最新版本，寫(xiě)入在CMDB 中已構(gòu)建的最終軟件庫(kù)（Definitive Software Library，DSL）；而將涉及到硬件的更新與安裝，映射到CMDB 的最終硬件庫(kù)（Definitive Hardware Store，DHS）中。

此舉不但能夠有效地保證了應(yīng)用系統(tǒng)及其服務(wù)的可靠性，又能夠及時(shí)地為后續(xù)的配置管理提供可參考的依據(jù)。也就是業(yè)界常說(shuō)的“及時(shí)更新基線”。

實(shí)務(wù)

我們本著給系統(tǒng)和服務(wù)“盡量做加法而不要做減法”的初衷，針對(duì)本企業(yè)內(nèi)部林林總總的產(chǎn)品類型，采用了如圖3 所示常規(guī)發(fā)布管理流程。

其中，在發(fā)布策略的規(guī)劃階段，我們會(huì)著重管理如下方面：

1.我們將待發(fā)布目標(biāo)區(qū)分為：標(biāo)準(zhǔn)/常規(guī)發(fā)布、緊急發(fā)布、以及項(xiàng)目發(fā)布，這三種類型，進(jìn)而根據(jù)解讀里提及的不同發(fā)布方式進(jìn)行了預(yù)定義。例如：

標(biāo)準(zhǔn)/常規(guī)發(fā)布適合于增量方式；

緊急發(fā)布適合于包方式；

項(xiàng)目發(fā)布更適合于全量方式。

當(dāng)然，我們也會(huì)根據(jù)實(shí)際情況略有調(diào)整。值得一提的是，我們?cè)谔幚韺?duì)外云端服務(wù)的相關(guān)更新與發(fā)布時(shí)，遵從了業(yè)界常用的灰度發(fā)布模式，即在保留一部分用戶繼續(xù)沿用老版本的同時(shí)，讓另一部分用戶開(kāi)始使用新的版本。

在并行使用期間，能夠及時(shí)地發(fā)現(xiàn)問(wèn)題，限制影響，甚至回滾調(diào)整。待用戶對(duì)于新版本體驗(yàn)反饋良好時(shí)，再逐步擴(kuò)大部署范圍，并最終將所有用戶都遷移過(guò)來(lái)。

2.在規(guī)范版本號(hào)編制的方面，我們采用了在業(yè)界普遍使用的軟件版本控制方法，即新的版本號(hào)由五個(gè)部分組成：“主版本號(hào)+子版本號(hào)+階段版本號(hào)+日期_希臘字母”。其中：

（1）主版本號(hào)的累加是指：在整體技術(shù)架構(gòu)上具有較大的變動(dòng)與調(diào)整。

（2）子版本號(hào)的累加是指：在服務(wù)與功能上具有增加或變化，比如增加了訪問(wèn)控制與授權(quán)、或是自定義的視圖等。

（3）階段版本號(hào)的累加是指：對(duì)現(xiàn)有服務(wù)進(jìn)行了Bug的修復(fù)或穩(wěn)定性的提升。

（3）日期：記錄的是修改完成的當(dāng)前日期。

（4）希臘字母：標(biāo)注的是當(dāng)前版本處于哪個(gè)開(kāi)發(fā)階段。Base 僅為Demo 版本，Alpha 為內(nèi)測(cè)版，Beta 為公測(cè)版，RC 為已成熟且無(wú)Bug的候選版，Release 為最終正式交付版。

在發(fā)布構(gòu)建、安裝與配置階段，我們采取的是自動(dòng)與手動(dòng)互補(bǔ)的方式。無(wú)疑，自動(dòng)化推送分發(fā)，包括DevOps里管道的運(yùn)用，可以保持發(fā)布的一致性，而且突破了時(shí)間和空間上的限制，進(jìn)而在一定程度上減輕了手動(dòng)部署的工作量。但是，對(duì)于一些自動(dòng)化過(guò)程中的遺漏，例如，未啟動(dòng)的主機(jī)和未上線的云端實(shí)例，則需要運(yùn)維人員以主動(dòng)拉取的方式，來(lái)完成并確認(rèn)。

在驗(yàn)收階段，我們除了需要確保只有正確的、被授權(quán)的以及經(jīng)過(guò)測(cè)試的軟/硬件版本出現(xiàn)在實(shí)際生產(chǎn)環(huán)境中之外，還應(yīng)當(dāng)及時(shí)更新CMDB里的CI，特別是對(duì)于已知錯(cuò)誤知識(shí)庫(kù)的維護(hù)。

在用戶支持和培訓(xùn)階段，我們可以充分利用已知錯(cuò)誤知識(shí)庫(kù)里的相關(guān)內(nèi)容，以積極的態(tài)度與用戶保持順暢的溝通，合理地控制好用戶在使用中的期望值和體驗(yàn)度，為“新品”保駕護(hù)航。