發布管理

基礎要點

發布內容既可以包括各種基礎架構、應用組件、更新流程與工具，也可以包括文檔與培訓。

發布管理工作通常發生在部署之前。

在傳統/瀑布環境中，發布管理和部署被合并為單個進程。

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

解讀

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

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

由此可見，發布管理的最終目標應該是：

實現并達到了預定的系統功能與服務級別；

更新了相應的配置管理數據庫（CMDB）；

保持了系統與服務的可用性與穩定性。

圖3 常規發布管理流程

由于發布往往會給系統和服務帶來更新，那么為了做好與配置相關的管理工作，我們勢必需要對基礎架構、應用組件、流程與工具、甚至是文檔與培訓等方面，做好相應的版本號編制工作。

就發布的類型而言，業界一般會采用三種傳統的發布方式：

1.增量發布（Delta Release）

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

2.全量發布（Full Release）

將更新部分連同原有不變的部分作為整體組件，發布到生產環境中。

包發布(Package Release)

將一組新的軟件或服務進行打包，然后直接導入既有的生產環境之中。

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

在執行發布之前，先讀取系統與服務的當前狀態，并錨定之。

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

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

實務

我們本著給系統和服務“盡量做加法而不要做減法”的初衷，針對本企業內部林林總總的產品類型，采用了如圖3 所示常規發布管理流程。

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

1.我們將待發布目標區分為：標準/常規發布、緊急發布、以及項目發布，這三種類型，進而根據解讀里提及的不同發布方式進行了預定義。例如：

標準/常規發布適合于增量方式；

緊急發布適合于包方式；

項目發布更適合于全量方式。

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

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

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

（1）主版本號的累加是指：在整體技術架構上具有較大的變動與調整。

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

（3）階段版本號的累加是指：對現有服務進行了Bug的修復或穩定性的提升。

（3）日期：記錄的是修改完成的當前日期。

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

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

在驗收階段，我們除了需要確保只有正確的、被授權的以及經過測試的軟/硬件版本出現在實際生產環境中之外，還應當及時更新CMDB里的CI，特別是對于已知錯誤知識庫的維護。

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