部署與發(fā)布：缺乏發(fā)布管理的部署活動對軟件交付是低效的

部署和發(fā)布是軟件工程中經(jīng)?；Q使用的兩個術語，甚至感覺是等價的。然而，它們是不同的！

• 部署是將軟件從一個受控環(huán)境轉(zhuǎn)移到另一個受控環(huán)境，它的目的是將軟件從開發(fā)狀態(tài)轉(zhuǎn)化為生產(chǎn)狀態(tài)，使得軟件可以為用戶提供服務。
• 發(fā)布是將軟件推向用戶的過程，應用程序需要多次更新、安全補丁和代碼更改，跨平臺和環(huán)境部署需要對版本進行適當?shù)墓芾恚?strong>有一定的計劃性和管控因素。

部署是發(fā)布的前提，只有當軟件已經(jīng)成功部署后，才能進行發(fā)布。缺乏發(fā)布管理會導致發(fā)布不規(guī)則、手動交付過程、數(shù)據(jù)庫更新問題、協(xié)作問題等。
如下，簡單歸納了發(fā)布&部署的差異：

部署、發(fā)布：概念區(qū)分

日常研發(fā)活動中，我們會經(jīng)常聽到下面的說法，感覺有點差別，又感覺一頭霧水說不清楚區(qū)別在哪里。

• 功能還沒集成進來。
• 功能還沒部署上去。
• 功能還沒交付。
• 功能還沒上線。
• 功能還沒發(fā)布。

下面對上述關鍵詞進行了總結歸納

集成（Integrate）

• 定義：將組成部分（部件）收集、歸攏，并建立它們之間的聯(lián)系或依賴關系，構建形成一個整體。
• DoD：通過驗證（驗收）測試，確認集成的結果是正確的。
• 說明：為了驗證集成的結果是正確的，需要對它（集成的結果）進行驗證（驗收）測試，而為了做驗證（驗收），需要將它（集成的結果）部署到一個環(huán)境中。但驗證（驗收）測試、部署，這些活動并不是集成，它們只是為了驗證集成達到了期望的結果。如果你能保證集成沒有問題，那么可以不做部署和驗收測試這2個動作。
• 特征：將分散的東西合并到一起，形成一個整體。
• 舉例：多個單元代碼通過集成，形成一個組件。多個組件或模塊通過集成，形成一個系統(tǒng)。多個系統(tǒng)通過集成，形成一個整體解決方案。

部署（Deploy）

• 定義：安裝、配置（如有）。
• DoD：通過驗證（驗收）測試，確認部署的結果是正確的（成功部署）。
• 說明：為了驗證部署的結果是正確的，需要對它（部署的結果）進行驗證（驗收）測試。但驗證（驗收）測試并不是部署，它只是為了驗證部署達到了期望的結果。如果你能保證部署沒有問題，那么可以不做驗收測試這個動作。
• 特征：將軟件“放置”到某個環(huán)境中。
• 舉例：部署人員將測試版本部署測試環(huán)境。將某個版本部署到試運行環(huán)境。將正式版本部署到生產(chǎn)環(huán)境。將一個模塊部署到系統(tǒng)中。

交付（Delivery）

• 定義：交給、付出、移交，指物（如軟件安裝包的光盤）或權（軟件的管理權、使用權、所有權等）在人與人之間的轉(zhuǎn)移、傳遞或接管。
• DoD：接收方確認收到（如簽收、同意）。
• 說明：接收方可能會對收到的物或權進行驗收測試，然后才簽收。但驗收測試、簽收并不是交付，它只是為了驗證交付的東西是期望的東西，它們是交付的下游動作。如果能保證交付物沒有問題，那么可以不做驗收測試、簽收這樣的動作。
• 特征：交付物或權的擁有者發(fā)生了“轉(zhuǎn)移”。
• 舉例：開發(fā)人員將測試版本交付給了測試人員。測試人員將正式版本交付給了運維人員。測試人員錯誤的將測試版本交付給了運維人員。IT團隊將系統(tǒng)交付給了業(yè)務部。某公司將軟件產(chǎn)品交付給了零售商。商店將軟件光盤交付給了用戶。這次只交付了一個模塊。

上線（Go-live / Ship）

• 定義：上到生成線，即部署到生產(chǎn)線上（生成環(huán)境中）
• DoD：在生產(chǎn)環(huán)境中可以看到，并可以使用。
• 說明：上線后，可以使用系統(tǒng)，也可以不使用系統(tǒng)。如果使用系統(tǒng)，開始創(chuàng)造業(yè)務價值，那么也叫投產(chǎn)（即投產(chǎn)=上線+使用系統(tǒng)）。如果上線后，不使用系統(tǒng)，那么表示系統(tǒng)還沒有“開工”，它并不影響上線這個動作?！笆褂孟到y(tǒng)”這個動作是上線后的下游活動，它不是“上線”活動的一部分。
• 特征：一定是部署到生產(chǎn)環(huán)境中（不是其它環(huán)境），即生產(chǎn)線上。上線 = 在生產(chǎn)環(huán)境上的部署。
• 舉例：IT部門上線了一個演示版。正式版剛剛上線，還沒有用戶訪問。某系統(tǒng)上線了半年，還沒有投產(chǎn)，某系統(tǒng)剛上線1個月，公司業(yè)績就得到了大幅提升。

發(fā)布（Release）

• 定義：將集成（構建）出來那個整體（發(fā)布對象），打上一個發(fā)布標簽，提供出來，受眾可以獲得。
• DoD：提供出來，受眾可以獲取到。
• 說明：發(fā)布的版本未必是正式版，比如發(fā)布測試版（如Beta版）、試用版、演示版。發(fā)布之后，受眾可以獲得軟件，但不一定就使用它。發(fā)布的軟件可以存儲在VCS（版本控制系統(tǒng)）中或制品庫中，也可以存儲在光盤等介質(zhì)上。受眾獲得軟件之后的下游動作，不一定是部署，也可能是其他動作（如交付或其他）。如：
  1. 發(fā)布測試版-->部署到測試環(huán)境-->交付給測試人員做驗收測試。
  2. 發(fā)布正式版-->部署到生產(chǎn)環(huán)境-->交付給用戶使用。
  3. 發(fā)布正式版產(chǎn)品（如windows安裝盤）-->（售賣）交付給用戶 --> 部署 -->上線使用。
• 特征：發(fā)布物有（標簽）標識，提供出來可以獲得。
• 舉例：開發(fā)人員發(fā)布了一個測試版。開發(fā)團隊在每個月都會發(fā)布一個演化版。某產(chǎn)品發(fā)布了新的版本，用戶需要重新購買后，才能部署升級。某云平臺發(fā)布了新的版本，不需要用戶部署就可以使用新的功能。本次版本發(fā)布了，但沒有人使用。

不同企業(yè)場景下的部署與發(fā)布

對于上面的概念解釋，可能你會覺得有什么用呢？能解決什么問題呢？不妨按照以上的定義，把開頭的那段話，進一步解讀，得到如下信息：

• 功能還沒集成進來 --> 功能還沒有被合并到一起，沒有形成一個整體。
• 功能還沒部署上去 --> 功能還沒有安裝、配置到指定的環(huán)境中。
• 功能還沒交付 --> 功能還沒有“轉(zhuǎn)移”給使用者。
• 功能還沒上線 --> 功能還沒有部署在生產(chǎn)環(huán)境。
• 功能還沒發(fā)布 --> 功能還沒有提供出來，不可以獲得。

除了集成是開發(fā)完成后首先完成的外，其它幾個活動沒有固定的依賴關系，它們的先后順序需要根據(jù)具體的應用場景。

場景1-2B項目交付

某乙方公司為甲方公司開發(fā)了一個web應用，需部署到生產(chǎn)環(huán)境，再發(fā)布給甲方公司，交付給使用部門（用戶），使用部門才能投產(chǎn)使用（上線），那么它們的先后順序就是：集成—>部署—>發(fā)布—>交付—>上線。

場景2-2B在線服務類

A公司開發(fā)了一個SaaS應用，部署到生產(chǎn)環(huán)境，交付給B公司，B公司再加入自己公司的基礎數(shù)據(jù)后上線了該SaaS應用，發(fā)布給使用部門（用戶）使用，那么它們的先后順序就是：集成—>部署—>交付—>上線—>發(fā)布。
還有更多場景，就不列舉了。

場景3-2B軟件售賣

A公司開發(fā)了一個商用軟件，發(fā)布到網(wǎng)上，B公司通過購買獲得，由A或B公司的技術員將軟件部署到B公司的生產(chǎn)環(huán)境，交給B公司的使用部門（用戶），使用部門才能投產(chǎn)使用（即上線），那么它們的先后順序就是：集成—>發(fā)布—>部署—>交付—>上線。

場景4-2C軟件包售賣

早年，微軟發(fā)布了Window XP（存儲在光盤中），交付給用戶，用戶再部署到生產(chǎn)環(huán)境，然后投產(chǎn)使用（上線）?，F(xiàn)在的很多單體軟件，大多也是這樣的流程。那么它們的先后順序就是：集成—>發(fā)布—>交付—>部署—>上線。

場景5-2C互聯(lián)網(wǎng)在線服務

對于互聯(lián)網(wǎng)應用服務，互聯(lián)網(wǎng)廠商一般會進行集成（頻率集成），通過自動化方式部署到dev/test/uat等環(huán)境，通過一定的審批機制獲得部署到prod環(huán)境的授權（藍綠、灰度等），正式發(fā)布上線，交付給用戶使用
那么它們的先后順序就是：集成—>部署—>發(fā)布—>上線—>交付
通過以上分析，你對“集成”、“部署”、“上線”、“交付”、“發(fā)布”的概念的理解是否清晰了？

吃透“部署發(fā)布”的重要性

上面說了這么多，目的不是為了死記某些概念，而是想說明，不同組織、產(chǎn)品形態(tài)不同，部署發(fā)布方式差異很大，在設計持續(xù)交付 (CD) 流程之前，需要了解關于部署、發(fā)布的素有信息。

有助于設計并優(yōu)化軟件交付流程

從代碼提交到集成，再到功能驗證，再到被部署到不同的環(huán)境，中間涉及了“代碼提交信息”，“制品信息”，“環(huán)境配置信息”等，不同的發(fā)布方式，這些信息的傳遞和保存方式也各不相同。理解吃透這些差異，才能設計出來有意義的交付流程。

• 如何集成涉及到了代碼倉庫的組織和構建流水線的設計
• 部署又和環(huán)境緊密聯(lián)系，還有部署策略
• 上線又會和審批流程有關系
• 發(fā)布就需要對制品進行晉級標簽的處理
• 交付就需要和制品的存儲/分發(fā)方式密切相關

部署發(fā)布的質(zhì)量取決于明確的發(fā)布計劃

另外，發(fā)布管理是ITIL服務管理框架中的一個重要流程，主要負責計劃、實施和控制IT服務的變更，確保變更過程中各個環(huán)節(jié)的順利進行。
發(fā)布管理關注的是將經(jīng)過測試并導入實際應用環(huán)境的新增或改進的配置項分發(fā)到最終用戶，并確保這些配置項能夠安全、可靠地運行。
因此需要在發(fā)布計劃、包和構建發(fā)送進行測試之前進行廣泛的規(guī)劃，主要涉及

• 發(fā)布單元具體業(yè)務需求及應用功能升級詳情
• 主要發(fā)布的發(fā)布數(shù)據(jù)
• 預定義的文檔流程
• 廣泛的測試計劃

另外，軟件版本需要適當?shù)墓芾硪员苊馀c未來版本相關的問題。

相關案例

這里，從不同角度歸納一些關于發(fā)布的案例。一般來說，需要提前制定發(fā)布計劃，并且由專人(例如release manager這樣的角色)負責管理發(fā)布計劃。release manager 作為研發(fā)團隊（研發(fā)執(zhí)行）和客戶（需求變更）之間的橋梁，清楚了解每次發(fā)布的變更，以及影響客戶的范圍。

案例-1 發(fā)布活動的協(xié)同

2016 年，聯(lián)合航空為超過 1.43 億用戶提供服務。然而，軟件發(fā)布管理是一個巨大的挑戰(zhàn)。有幾個手動流程和電子表格，這增加了發(fā)布周期時間。
因此，聯(lián)合航空公司選擇通過轉(zhuǎn)移發(fā)布團隊的角色來利用在岸/離岸發(fā)布模型，以確保完成特定的承諾。他們的發(fā)布管理方法最好的部分是使用 DevOps 和集中治理模型。他們設法通過持續(xù)交付團隊 (CDT) 和開發(fā)團隊之間的協(xié)作來簡化發(fā)布。

案例-2 Firefox的發(fā)布火車

Firefox的發(fā)布流程：每個獨立的發(fā)布火車（新的發(fā)布過程采用火車模型，固定的“發(fā)車”時間，特性的發(fā)布取決于該特性是否趕上最近的火車發(fā)車時間）包括6周的開發(fā)時間加上12周的穩(wěn)定時間：

除了發(fā)布計劃，這里也需要分支策略的配合 （新的開發(fā)成果不會直接發(fā)布到Aurora和Beta分支上，這些分支需要被開發(fā)人員和社區(qū)測試人員共同測試完方可；如果發(fā)現(xiàn)開發(fā)中存在程序問題或者BUG，就需要先解決問題）

案例-3 支持發(fā)布的平臺Zadig

對于發(fā)布，市場上少有平臺會關注這個環(huán)節(jié)。筆者過去見過的團隊，一般都會用一個excel表格的方式來記錄各個版本的變更，以及發(fā)布的客戶范圍。
這里介紹Zadig平臺中的“發(fā)布管理”模塊，特別是對于2B場景，可能面對很多不同客戶，包括不同的定制， 需要一個平臺來匯總這些信息，包括

• 發(fā)布版本管理-與產(chǎn)品版本規(guī)規(guī)劃對齊，首尾呼應，形成閉環(huán)

• 發(fā)布審批 - 對于直接對線上的正式環(huán)境，需要配合自動化的流水線，取得管理人員的審批

• 客戶管理- 最終的交付物最終給哪個客戶，需要明確的體現(xiàn)出來

目前，Zadig更多是針對于客戶SAAS服務，直接面對線上環(huán)境，所以還會有線上基礎設施云供應商的配置。
這里其實可以拓展更多，比如對于私有化部署場景，這里交付的可能是部署包，數(shù)據(jù)庫文件等等。

最后

上面從部署發(fā)布的概念，不同場景，到案例工具進行了總結，希望能對大家有所啟發(fā)~
下面歸納了可能影響發(fā)布的關鍵要素。部署發(fā)布是軟件交付的最后一公里，呼應了產(chǎn)品的發(fā)布計劃，有序的發(fā)布管理和流程，會讓價值交付更加清晰透明，取代混亂和低效。

• 版本發(fā)布計劃/需求變更
• 版本發(fā)布流程/人員
• 分支策略
• 部署策略
• 環(huán)境/配置管理
• 制品晉級/標簽

注：部分內(nèi)容參考網(wǎng)絡資料，如有侵權請聯(lián)系我