發布管理、部署管理、持續交付，這些概念在實際的運維落地中往往讓大家很頭疼，尤其是在有研發團隊的IT組織中更是如此，發布、部署、交付到底管理的那一段呢？在實際的運維落地中我們該如何應用呢？今天我們就聊聊這個話題。

發布、部署和交付的概念

還是我們一貫的風格，我們在使用一個理論、方法時先要理清楚它們的概念，概念明確了，邊界也基本清楚了。發布管理、部署管理、持續集成、持續部署、持續交付涉及到ITIL4和DevOps兩個知識體系。

ITIL4中的定義：

持續集成（Continuous integration）：在軟件開發環境中集成（Integrating）、構建（building）和測試（ testing）代碼。

持續交付（Continuous Delivery）:持續交付意味著構建好的軟件可以隨時發布到生產環境中。但通常情況下，組織更喜歡較慢的部署速率，因此發布決策是根據情況逐案（case by case）做出的。

部署（ deploymen）：將任何服務組件移動到任何環境中。

在一些組織中，“供應/配置（provisioning）”一詞是指對基礎架構的部署，而部署一詞僅指軟件部署，不過在當前介紹的情況下，“部署”一詞同時兼具這兩層含義，即部署即包括IT基礎設施硬件的安裝配置，也包括對應用系統軟件版本的部署。

持續部署（Continuous deployment）:變更會通過流水線自動發布到生產環境中,每天可以進行多次生產部署。持續部署依賴持續交付。

部署管理（ Deployment Management）：部署管理實踐的目的在于將新的或變更的硬件、軟件、文檔、流程或其它服務組件移至生產環境中。

但是，部署不僅僅是生產環境的部署，可以涉及將組件部署至不同環境，以用于測試或預發布。

環境（Environment）：用于特定目的IT基礎設施的子集，比如包括服務器、中間件、數據庫、網絡等。常見的環境包括：開發/集成環境、測試環境、預發布環境、生產環境。

發布（Release）：某一服務或其它配置項或者一系列配置項可供（最終用戶）使用的一個版本。

注：ITIL4中的發布管理是針對最終用戶的發布，發布的是最終用戶可用的功能、特性或服務。

發布管理（Release  management）：發布管理實踐的目的在于提供新的和變更的服務與特性以供（最終用戶）使用。

發布管理針對的兩種應用場景

對于發布管理在實際落地時根據發布對象的不同有兩種應用場景。

場景1：針對最終用戶的發布

ITIL4的發布管理中說的就是這種應用場景，即我們的發布是確保最終用戶的“使服務或任何其他配置項的版本或配置項的集合可用。”可以用如下的示意圖表示：

這種場景的發布通常是由變更管理觸發，或者發布管理可以作為變更實施中的子流程。此時發布管理的主要目的就是確保計劃變更的內容（通常指的是軟件）針對最終用戶可用。

此場景下部署管理是確保有一個可以供運維部門測試、驗證的環境。

此種場景下流程的負責人是運維部門，此場景的流程圖如下：

場景2：研發針對運維的發布（不屬于運維）

在這種場景下往往是研發的視角，研發工程師把軟件集成后可以形成一個可供測試的軟件版本，這個過程屬于研發端的“發布管理”，不屬于ITIL4中定義的發布管理的范疇了，可以更傾向于理解是一種測試發布。所以我們在使用發布管理和部署管理的時候一定要明確我們是在那個場景中。此場景下的示意圖如下：

理解了發布的場景后，部署管理的作用也就明確了，在不同的場景下，部署管理的階段是不同的。我們在運維中可以使用部署管理來管理針對用戶版本的發布的部署、也可以用來管理在測試環境中的部署。

變更管理中的變更實施與發布和部署的關系？

在實際的落地過程中，變更的涉及范圍是比較大的，可能是針對軟件系統、硬件系統的某個參數、權限的變更，也可能是其他IT組件的增刪改。通常我們把針對軟件系統、硬件設備內置系統的升級、新功能增加等涉及到需要嚴格測試、分步實施的場景中來使用發布管理和部署管理來管控。而針對與原有功能不變的增刪改直接使用變更實施環節就可以。如果下面的流程中就是變更實施中嵌入發布管理和部署管理子流程。

部署管理僅是指生產環境的部署嗎？

不是，ITIL4中定義的部署不僅僅包括向生產環境部署，還包括測試環境部署、預發布環境部署等。通過部署管理是讓內部測試人員有了一個可以測試的環境或者是可以提供預發布的環境供最終發布給用戶使用。

從端到端的場景理解：部署、發布、交付

在實際的工作中我們還可能遇到針對軟件的集成、部署、發布、交付、上線等術語，至于它們的依賴關系，即誰先誰后，除了集成是首先要完成的，其它幾個活動沒有固定的依賴關系，它們的先后順序需要根據具體的應用場景，例如：

場景1：某乙方公司為甲方公司開發了一個web應用，需部署到生產環境，再發布給甲方公司，交付給使用部門(用戶),使用部門才能投產使用(上線) ,那么它們的先后順序就是: 集成—>部署—>發布—>交付—>上線。
  場景2：A公司開發了一個商用軟件，發布到網上，B公司通過購買獲得，由A或B公司的技術員將軟件部署到B公司的生產環境,交給B公司的使用部門(用戶),使用部門才能投產使用（即上線) ,那么它們的先后順序就是: 集成—>發布—>部署—>交付—>上線。

場景3：例如,微軟發布了Window (存儲在光盤中),交付給用戶,用戶再部署到生產環境,然后投產使用（上線)。現在的很多單體軟件,大多也是這樣的流程。那么它們的先后順序就是：集成—>發布—>交付—>部署—>上線。

場景4：A公司開發了一個SaaS應用,部署到生產環境，交付給B公司，B公司再加入自己公司的基礎數據后上線了該SaaS應用,發布給使用部門(用戶)使用,那么它們的先后順序就是: 集成—>部署—>交付—>上線—>發布。

綜上，我們在落地的過程中除了區分關鍵的概念外，還是要充分考慮應用的場景，同樣的術語在不同的場景下可能活動是不同的，需要控制的內容也一樣，因此，首先明確自己面臨的問題、期望達到的管理目標、預期看到的結果，然后再結合各個知識體系做出適合自己組織的管理流程和管理辦法。