發(fā)布管理、部署管理、持續(xù)交付，這些概念在實(shí)際的運(yùn)維落地中往往讓大家很頭疼，尤其是在有研發(fā)團(tuán)隊的IT組織中更是如此，發(fā)布、部署、交付到底管理的那一段呢？在實(shí)際的運(yùn)維落地中我們該如何應(yīng)用呢？今天我們就聊聊這個話題。
發(fā)布、部署和交付的概念
還是我們一貫的風(fēng)格，我們在使用一個理論、方法時先要理清楚它們的概念，概念明確了，邊界也基本清楚了。發(fā)布管理、部署管理、持續(xù)集成、持續(xù)部署、持續(xù)交付涉及到ITIL4和DevOps兩個知識體系。
ITIL4中的定義：
持續(xù)集成（Continuous integration）：在軟件開發(fā)環(huán)境中集成（Integrating）、構(gòu)建（building）和測試（ testing）代碼。
持續(xù)交付（Continuous Delivery）:持續(xù)交付意味著構(gòu)建好的軟件可以隨時發(fā)布到生產(chǎn)環(huán)境中。但通常情況下，組織更喜歡較慢的部署速率，因此發(fā)布決策是根據(jù)情況逐案（case by case）做出的。
部署（ deploymen）：將任何服務(wù)組件移動到任何環(huán)境中。
在一些組織中，“供應(yīng)/配置（provisioning）”一詞是指對基礎(chǔ)架構(gòu)的部署，而部署一詞僅指軟件部署，不過在當(dāng)前介紹的情況下，“部署”一詞同時兼具這兩層含義，即部署即包括IT基礎(chǔ)設(shè)施硬件的安裝配置，也包括對應(yīng)用系統(tǒng)軟件版本的部署。
持續(xù)部署（Continuous deployment）:變更會通過流水線自動發(fā)布到生產(chǎn)環(huán)境中,每天可以進(jìn)行多次生產(chǎn)部署。持續(xù)部署依賴持續(xù)交付。
部署管理（ Deployment Management）：部署管理實(shí)踐的目的在于將新的或變更的硬件、軟件、文檔、流程或其它服務(wù)組件移至生產(chǎn)環(huán)境中。
但是，部署不僅僅是生產(chǎn)環(huán)境的部署，可以涉及將組件部署至不同環(huán)境，以用于測試或預(yù)發(fā)布。
環(huán)境（Environment）：用于特定目的IT基礎(chǔ)設(shè)施的子集，比如包括服務(wù)器、中間件、數(shù)據(jù)庫、網(wǎng)絡(luò)等。常見的環(huán)境包括：開發(fā)/集成環(huán)境、測試環(huán)境、預(yù)發(fā)布環(huán)境、生產(chǎn)環(huán)境。
發(fā)布（Release）：某一服務(wù)或其它配置項或者一系列配置項可供（最終用戶）使用的一個版本。
注：ITIL4中的發(fā)布管理是針對最終用戶的發(fā)布，發(fā)布的是最終用戶可用的功能、特性或服務(wù)。
發(fā)布管理（Release management）：發(fā)布管理實(shí)踐的目的在于提供新的和變更的服務(wù)與特性以供（最終用戶）使用。
發(fā)布管理針對的兩種應(yīng)用場景
對于發(fā)布管理在實(shí)際落地時根據(jù)發(fā)布對象的不同有兩種應(yīng)用場景。
場景1：針對最終用戶的發(fā)布
ITIL4的發(fā)布管理中說的就是這種應(yīng)用場景，即我們的發(fā)布是確保最終用戶的“使服務(wù)或任何其他配置項的版本或配置項的集合可用。”可以用如下的示意圖表示：
這種場景的發(fā)布通常是由變更管理觸發(fā)，或者發(fā)布管理可以作為變更實(shí)施中的子流程。此時發(fā)布管理的主要目的就是確保計劃變更的內(nèi)容（通常指的是軟件）針對最終用戶可用。
此場景下部署管理是確保有一個可以供運(yùn)維部門測試、驗證的環(huán)境。
此種場景下流程的負(fù)責(zé)人是運(yùn)維部門，此場景的流程圖如下：
場景2：研發(fā)針對運(yùn)維的發(fā)布（不屬于運(yùn)維）
在這種場景下往往是研發(fā)的視角，研發(fā)工程師把軟件集成后可以形成一個可供測試的軟件版本，這個過程屬于研發(fā)端的“發(fā)布管理”，不屬于ITIL4中定義的發(fā)布管理的范疇了，可以更傾向于理解是一種測試發(fā)布。所以我們在使用發(fā)布管理和部署管理的時候一定要明確我們是在那個場景中。此場景下的示意圖如下：
理解了發(fā)布的場景后，部署管理的作用也就明確了，在不同的場景下，部署管理的階段是不同的。我們在運(yùn)維中可以使用部署管理來管理針對用戶版本的發(fā)布的部署、也可以用來管理在測試環(huán)境中的部署。
變更管理中的變更實(shí)施與發(fā)布和部署的關(guān)系？
在實(shí)際的落地過程中，變更的涉及范圍是比較大的，可能是針對軟件系統(tǒng)、硬件系統(tǒng)的某個參數(shù)、權(quán)限的變更，也可能是其他IT組件的增刪改。通常我們把針對軟件系統(tǒng)、硬件設(shè)備內(nèi)置系統(tǒng)的升級、新功能增加等涉及到需要嚴(yán)格測試、分步實(shí)施的場景中來使用發(fā)布管理和部署管理來管控。而針對與原有功能不變的增刪改直接使用變更實(shí)施環(huán)節(jié)就可以。如果下面的流程中就是變更實(shí)施中嵌入發(fā)布管理和部署管理子流程。
部署管理僅是指生產(chǎn)環(huán)境的部署嗎？
不是，ITIL4中定義的部署不僅僅包括向生產(chǎn)環(huán)境部署，還包括測試環(huán)境部署、預(yù)發(fā)布環(huán)境部署等。通過部署管理是讓內(nèi)部測試人員有了一個可以測試的環(huán)境或者是可以提供預(yù)發(fā)布的環(huán)境供最終發(fā)布給用戶使用。
從端到端的場景理解：部署、發(fā)布、交付
在實(shí)際的工作中我們還可能遇到針對軟件的集成、部署、發(fā)布、交付、上線等術(shù)語，至于它們的依賴關(guān)系，即誰先誰后，除了集成是首先要完成的，其它幾個活動沒有固定的依賴關(guān)系，它們的先后順序需要根據(jù)具體的應(yīng)用場景，例如：
場景1：某乙方公司為甲方公司開發(fā)了一個web應(yīng)用，需部署到生產(chǎn)環(huán)境，再發(fā)布給甲方公司，交付給使用部門(用戶),使用部門才能投產(chǎn)使用(上線) ,那么它們的先后順序就是: 集成—>部署—>發(fā)布—>交付—>上線。
場景2：A公司開發(fā)了一個商用軟件，發(fā)布到網(wǎng)上，B公司通過購買獲得，由A或B公司的技術(shù)員將軟件部署到B公司的生產(chǎn)環(huán)境,交給B公司的使用部門(用戶),使用部門才能投產(chǎn)使用（即上線) ,那么它們的先后順序就是: 集成—>發(fā)布—>部署—>交付—>上線。
場景3：例如,微軟發(fā)布了Window (存儲在光盤中),交付給用戶,用戶再部署到生產(chǎn)環(huán)境,然后投產(chǎn)使用（上線)。現(xiàn)在的很多單體軟件,大多也是這樣的流程。那么它們的先后順序就是：集成—>發(fā)布—>交付—>部署—>上線。
場景4：A公司開發(fā)了一個SaaS應(yīng)用,部署到生產(chǎn)環(huán)境，交付給B公司，B公司再加入自己公司的基礎(chǔ)數(shù)據(jù)后上線了該SaaS應(yīng)用,發(fā)布給使用部門(用戶)使用,那么它們的先后順序就是: 集成—>部署—>交付—>上線—>發(fā)布。
綜上，我們在落地的過程中除了區(qū)分關(guān)鍵的概念外，還是要充分考慮應(yīng)用的場景，同樣的術(shù)語在不同的場景下可能活動是不同的，需要控制的內(nèi)容也一樣，因此，首先明確自己面臨的問題、期望達(dá)到的管理目標(biāo)、預(yù)期看到的結(jié)果，然后再結(jié)合各個知識體系做出適合自己組織的管理流程和管理辦法。
