發(fā)布管理

基礎(chǔ)要點

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

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

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

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

解讀

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

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

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

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

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

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

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

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

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

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

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

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

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

包發(fā)布(Package Release)

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

如前所述，無論我們在實際操作中采取哪一種發(fā)布方式，都會涉及到對于CMDB 進(jìn)行相關(guān)配置項（CI）的簽出（check out）和簽入（check in）的過程。即：

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

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

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

實務(wù)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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