部署與發佈：缺乏發佈管理的部署活動對軟件交付是低效的
部署和發佈是軟件工程中經常互換使用的兩個術語，甚至感覺是等價的。然而，它們是不同的！
- 部署是將軟件從一個受控環境轉移到另一個受控環境，它的目的是將軟件從開發狀態轉化爲生產狀態，使得軟件可以爲用戶提供服務。
- 發佈是將軟件推向用戶的過程，應用程序需要多次更新、安全補丁和代碼更改，跨平臺和環境部署需要對版本進行適當的管理，有一定的計劃性和管控因素。
部署是發佈的前提，只有當軟件已經成功部署後，才能進行發佈。缺乏發佈管理會導致發佈不規則、手動交付過程、數據庫更新問題、協作問題等。
如下，簡單歸納了發佈&部署的差異：
部署、發佈：概念區分
日常研發活動中，我們會經常聽到下面的說法，感覺有點差別，又感覺一頭霧水說不清楚區別在哪裏。
- 功能還沒集成進來。
- 功能還沒部署上去。
- 功能還沒交付。
- 功能還沒上線。
- 功能還沒發佈。
下面對上述關鍵詞進行了總結歸納
集成（Integrate）
- 定義：將組成部分（部件）收集、歸攏，並建立它們之間的聯繫或依賴關係，構建形成一個整體。
- DoD：通過驗證（驗收）測試，確認集成的結果是正確的。
- 說明：爲了驗證集成的結果是正確的，需要對它（集成的結果）進行驗證（驗收）測試，而爲了做驗證（驗收），需要將它（集成的結果）部署到一個環境中。但驗證（驗收）測試、部署，這些活動並不是集成，它們只是爲了驗證集成達到了期望的結果。如果你能保證集成沒有問題，那麼可以不做部署和驗收測試這2個動作。
- 特徵：將分散的東西合併到一起，形成一個整體。
- 舉例：多個單元代碼通過集成，形成一個組件。多個組件或模塊通過集成，形成一個系統。多個系統通過集成，形成一個整體解決方案。
部署（Deploy）
- 定義：安裝、配置（如有）。
- DoD：通過驗證（驗收）測試，確認部署的結果是正確的（成功部署）。
- 說明：爲了驗證部署的結果是正確的，需要對它（部署的結果）進行驗證（驗收）測試。但驗證（驗收）測試並不是部署，它只是爲了驗證部署達到了期望的結果。如果你能保證部署沒有問題，那麼可以不做驗收測試這個動作。
- 特徵：將軟件“放置”到某個環境中。
- 舉例：部署人員將測試版本部署測試環境。將某個版本部署到試運行環境。將正式版本部署到生產環境。將一個模塊部署到系統中。
交付（Delivery）
- 定義：交給、付出、移交，指物（如軟件安裝包的光盤）或權（軟件的管理權、使用權、所有權等）在人與人之間的轉移、傳遞或接管。
- DoD：接收方確認收到（如簽收、同意）。
- 說明：接收方可能會對收到的物或權進行驗收測試，然後才簽收。但驗收測試、簽收並不是交付，它只是爲了驗證交付的東西是期望的東西，它們是交付的下游動作。如果能保證交付物沒有問題，那麼可以不做驗收測試、簽收這樣的動作。
- 特徵：交付物或權的擁有者發生了“轉移”。
- 舉例：開發人員將測試版本交付給了測試人員。測試人員將正式版本交付給了運維人員。測試人員錯誤的將測試版本交付給了運維人員。IT團隊將系統交付給了業務部。某公司將軟件產品交付給了零售商。商店將軟件光盤交付給了用戶。這次只交付了一個模塊。
上線（Go-live / Ship）
- 定義：上到生成線，即部署到生產線上（生成環境中）
- DoD：在生產環境中可以看到，並可以使用。
- 說明：上線後，可以使用系統，也可以不使用系統。如果使用系統，開始創造業務價值，那麼也叫投產（即投產=上線+使用系統）。如果上線後，不使用系統，那麼表示系統還沒有“開工”，它並不影響上線這個動作。“使用系統”這個動作是上線後的下游活動，它不是“上線”活動的一部分。
- 特徵：一定是部署到生產環境中（不是其它環境），即生產線上。上線 = 在生產環境上的部署。
- 舉例：IT部門上線了一個演示版。正式版剛剛上線，還沒有用戶訪問。某系統上線了半年，還沒有投產，某系統剛上線1個月，公司業績就得到了大幅提升。
發佈（Release）
- 定義：將集成（構建）出來那個整體（發佈對象），打上一個發佈標籤，提供出來，受衆可以獲得。
- DoD：提供出來，受衆可以獲取到。
- 說明：發佈的版本未必是正式版，比如發佈測試版（如Beta版）、試用版、演示版。發佈之後，受衆可以獲得軟件，但不一定就使用它。發佈的軟件可以存儲在VCS（版本控制系統）中或製品庫中，也可以存儲在光盤等介質上。受衆獲得軟件之後的下游動作，不一定是部署，也可能是其他動作（如交付或其他）。如：
- 發佈測試版-->部署到測試環境-->交付給測試人員做驗收測試。
- 發佈正式版-->部署到生產環境-->交付給用戶使用。
- 發佈正式版產品（如windows安裝盤）-->（售賣）交付給用戶 --> 部署 -->上線使用。
- 特徵：發佈物有（標籤）標識，提供出來可以獲得。
- 舉例：開發人員發佈了一個測試版。開發團隊在每個月都會發佈一個演化版。某產品發佈了新的版本，用戶需要重新購買後，才能部署升級。某雲平臺發佈了新的版本，不需要用戶部署就可以使用新的功能。本次版本發佈了，但沒有人使用。
不同企業場景下的部署與發佈
對於上面的概念解釋，可能你會覺得有什麼用呢？能解決什麼問題呢？不妨按照以上的定義，把開頭的那段話，進一步解讀，得到如下信息：
- 功能還沒集成進來 --> 功能還沒有被合併到一起，沒有形成一個整體。
- 功能還沒部署上去 --> 功能還沒有安裝、配置到指定的環境中。
- 功能還沒交付 --> 功能還沒有“轉移”給使用者。
- 功能還沒上線 --> 功能還沒有部署在生產環境。
- 功能還沒發佈 --> 功能還沒有提供出來，不可以獲得。
除了集成是開發完成後首先完成的外，其它幾個活動沒有固定的依賴關係，它們的先後順序需要根據具體的應用場景。
場景1-2B項目交付
某乙方公司爲甲方公司開發了一個web應用，需部署到生產環境，再發布給甲方公司，交付給使用部門（用戶），使用部門才能投產使用（上線），那麼它們的先後順序就是：集成—>部署—>發佈—>交付—>上線。
場景2-2B在線服務類
A公司開發了一個SaaS應用，部署到生產環境，交付給B公司，B公司再加入自己公司的基礎數據後上線了該SaaS應用，發佈給使用部門（用戶）使用，那麼它們的先後順序就是：集成—>部署—>交付—>上線—>發佈。
還有更多場景，就不列舉了。
場景3-2B軟件售賣
A公司開發了一個商用軟件，發佈到網上，B公司通過購買獲得，由A或B公司的技術員將軟件部署到B公司的生產環境，交給B公司的使用部門（用戶），使用部門才能投產使用（即上線），那麼它們的先後順序就是：集成—>發佈—>部署—>交付—>上線。
場景4-2C軟件包售賣
早年，微軟發佈了Window XP（存儲在光盤中），交付給用戶，用戶再部署到生產環境，然後投產使用（上線）。現在的很多單體軟件，大多也是這樣的流程。那麼它們的先後順序就是：集成—>發佈—>交付—>部署—>上線。
場景5-2C互聯網在線服務
對於互聯網應用服務，互聯網廠商一般會進行集成（頻率集成），通過自動化方式部署到dev/test/uat等環境，通過一定的審批機制獲得部署到prod環境的授權（藍綠、灰度等），正式發佈上線，交付給用戶使用
那麼它們的先後順序就是：集成—>部署—>發佈—>上線—>交付
通過以上分析，你對“集成”、“部署”、“上線”、“交付”、“發佈”的概念的理解是否清晰了？
喫透“部署發佈”的重要性
上面說了這麼多，目的不是爲了死記某些概念，而是想說明，不同組織、產品形態不同，部署發佈方式差異很大，在設計持續交付 (CD) 流程之前，需要了解關於部署、發佈的素有信息。
有助於設計並優化軟件交付流程
從代碼提交到集成，再到功能驗證，再到被部署到不同的環境，中間涉及了“代碼提交信息”，“製品信息”，“環境配置信息”等，不同的發佈方式，這些信息的傳遞和保存方式也各不相同。理解喫透這些差異，才能設計出來有意義的交付流程。
- 如何集成涉及到了代碼倉庫的組織和構建流水線的設計
- 部署又和環境緊密聯繫，還有部署策略
- 上線又會和審批流程有關係
- 發佈就需要對製品進行晉級標籤的處理
- 交付就需要和製品的存儲/分發方式密切相關
部署發佈的質量取決於明確的發佈計劃
另外，發佈管理是ITIL服務管理框架中的一個重要流程，主要負責計劃、實施和控制IT服務的變更，確保變更過程中各個環節的順利進行。
發佈管理關注的是將經過測試並導入實際應用環境的新增或改進的配置項分發到最終用戶，並確保這些配置項能夠安全、可靠地運行。
因此需要在發佈計劃、包和構建發送進行測試之前進行廣泛的規劃，主要涉及
- 發佈單元具體業務需求及應用功能升級詳情
- 主要發佈的發佈數據
- 預定義的文檔流程
- 廣泛的測試計劃
另外，軟件版本需要適當的管理以避免與未來版本相關的問題。
相關案例
這裏，從不同角度歸納一些關於發佈的案例。一般來說，需要提前制定發佈計劃，並且由專人(例如release manager這樣的角色)負責管理髮布計劃。release manager 作爲研發團隊（研發執行）和客戶（需求變更）之間的橋樑，清楚瞭解每次發佈的變更，以及影響客戶的範圍。
案例-1 發佈活動的協同
2016 年，聯合航空爲超過 1.43 億用戶提供服務。然而，軟件發佈管理是一個巨大的挑戰。有幾個手動流程和電子表格，這增加了發佈週期時間。
因此，聯合航空公司選擇通過轉移發佈團隊的角色來利用在岸/離岸發佈模型，以確保完成特定的承諾。他們的發佈管理方法最好的部分是使用 DevOps 和集中治理模型。他們設法通過持續交付團隊 (CDT) 和開發團隊之間的協作來簡化發佈。
案例-2 Firefox的發佈火車
Firefox的發佈流程：每個獨立的發佈火車（新的發佈過程採用火車模型，固定的“發車”時間，特性的發佈取決於該特性是否趕上最近的火車發車時間）包括6周的開發時間加上12周的穩定時間：
除了發佈計劃，這裏也需要分支策略的配合 （新的開發成果不會直接發佈到Aurora和Beta分支上，這些分支需要被開發人員和社區測試人員共同測試完方可；如果發現開發中存在程序問題或者BUG，就需要先解決問題）
案例-3 支持發佈的平臺Zadig
對於發佈，市場上少有平臺會關注這個環節。筆者過去見過的團隊，一般都會用一個excel表格的方式來記錄各個版本的變更，以及發佈的客戶範圍。
這裏介紹Zadig平臺中的“發佈管理”模塊，特別是對於2B場景，可能面對很多不同客戶，包括不同的定製， 需要一個平臺來彙總這些信息，包括
- 發佈版本管理-與產品版本規規劃對齊，首尾呼應，形成閉環
- 發佈審批 - 對於直接對線上的正式環境，需要配合自動化的流水線，取得管理人員的審批
- 客戶管理- 最終的交付物最終給哪個客戶，需要明確的體現出來
目前，Zadig更多是針對於客戶SAAS服務，直接面對線上環境，所以還會有線上基礎設施雲供應商的配置。
這裏其實可以拓展更多，比如對於私有化部署場景，這裏交付的可能是部署包，數據庫文件等等。
最後
上面從部署發佈的概念，不同場景，到案例工具進行了總結，希望能對大家有所啓發~
下面歸納了可能影響發佈的關鍵要素。部署發佈是軟件交付的最後一公里，呼應了產品的發佈計劃，有序的發佈管理和流程，會讓價值交付更加清晰透明，取代混亂和低效。
- 版本發佈計劃/需求變更
- 版本發佈流程/人員
- 分支策略
- 部署策略
- 環境/配置管理
- 製品晉級/標籤
注：部分內容參考網絡資料，如有侵權請聯繫我
