敏捷：你能區分DevOps中的「集成、部署、交付、上線、發佈」嗎？

在DevOps中，你可能常常會聽到相似這樣的一些話：

功能還沒集成進來。

功能還沒部署上去。

功能還沒交付。

功能還沒上線。

功能還沒發佈。

請問，以上「集成」、「部署」、 「交付」、「上線」、「發佈」這幾個概念，表達的是同一個意思嗎？若是不是，它們有什麼區別呢？

我相信大多數人都會爲此而迷茫，本人也經常被這幾個術語搞暈。

也許你會說，上面的例子太簡單，難於判斷。好吧，下面再給你一些更多的例子（均來自DOM【DevOps Master，簡稱DOM】認證課程的權威教材）：

還要再花幾天才能把這個新版本發佈到UAT環境中。

上次發佈新版本到生產環境時，你花掉了整個週末的時間。

一行代碼的改動須要花多長時間才能部署上線。

每次提交代碼均可能產生一個可發佈的版本。

不少公司都會在一天內發佈不少次。

遵循極限編程的座右銘：若是它令你很受傷，那麼就作更多的練習（If it hurts, do it more often）。合乎邏輯的極限就是每當有版本經過自動化測試以後，就將其部署到生產環境中。這種技術叫作「持續部署」，Timothy Fitz發明的一個術語。

持續交付指的是應用程序的構建、部署、測試和發佈的自動化流程。

由良好的金絲雀發佈系統提供的這層安全網讓持續部署的風險甚至更小。

有些人反對持續部署，在直覺上，這麼作的風險過高。但如前所述，越頻繁的發佈會讓發佈風險越低。

根據咱們的經驗，作這件事的最佳方法就是儘量頻繁地發佈（即持續交付)。

持續交付目標是讓應用程序保持在可發佈狀態。

對於組織來講，持續交付不只僅是一種部署方法。

如今，你是否能區分開「集成」、「部署」、「交付」、「上線」、「發佈」這幾個概念了呢？

一頭霧水！對，至少我本身仍然還不明白它們的區別。爲此，我查閱了一些資料，但仍然不得解。網上的各類文章裏有各類不一樣的解釋，但要麼是侷限在特定的上下文環境中，要麼是混淆使用，老是經不起推敲。

形成以上的混亂，我以爲多是缺乏對上述術語的標準定義和準確的描述。

怎樣才能不被「繞暈」？我在不斷的思考，也與一些同行探討過，甚至曾經嘗試使用表格的方式，從這幾個術語所表明的活動操做執行者、執行時間、執行對象、執行環境、執行方法/方式、產出物、接收者（受衆）等多個維度進行對比和區別，但最後又成功的把本身「繞」暈了。

在第五空間學習中心的DevOps Master課堂上，受許峯老師關於DoD（Done of Definition，簡稱DoD，指完成的定義）的啓發，我以爲這些術語都表明了一種活動，活動之間會存在某種聯繫或依賴，因此下面嘗試從DoD的角度（用下游的活動來確認上游活動是否真正完成）來解釋和區分下這些術語。

集成（Integrate）

定義：將組成部分（部件）收集、歸攏，並創建它們之間的聯繫或依賴關係，構建造成一個總體。

DoD：經過驗證（驗收）測試，確認集成的結果是正確的。

說明：爲了驗證集成的結果是正確的，須要對它（集成的結果）進行驗證（驗收）測試，而爲了作驗證（驗收），須要將它（集成的結果）部署到一個環境中。但驗證（驗收）測試、部署，這些活動並非集成，它們只是爲了驗證集成達到了指望的結果。若是你能保證集成沒有問題，那麼能夠不作部署和驗收測試這2個動做。

特徵：將分散的東西合併到一塊兒，造成一個總體。

舉例：多個單元代碼經過集成，造成一個組件。多個組件或模塊經過集成，造成一個系統。多個系統經過集成，造成一個總體解決方案。

部署（Deploy）

定義：安裝、配置（若有）。

DoD：經過驗證（驗收）測試，確認部署的結果是正確的（成功部署）。

說明：爲了驗證部署的結果是正確的，須要對它（部署的結果）進行驗證（驗收）測試。但驗證（驗收）測試並非部署，它只是爲了驗證部署達到了指望的結果。若是你能保證部署沒有問題，那麼能夠不作驗收測試這個動做。

特徵：將軟件「放置」到某個環境中。

舉例：部署人員將測試版本部署測試環境。將某個版本部署到試運行環境。將正式版本部署到生產環境。將一個模塊部署到系統中。

交付（Delivery）

定義：交給、付出、移交，指物（如軟件安裝包的光盤）或權（軟件的管理權、使用權、全部權等）在人與人之間的轉移、傳遞或接管。

DoD：接收方確認收到（如簽收、贊成）。

說明：接收方可能會對收到的物或權進行驗收測試，而後才簽收。但驗收測試、簽收並非交付，它只是爲了驗證交付的東西是指望的東西，它們是交付的下游動做。若是能保證交付物沒有問題，那麼能夠不作驗收測試、簽收這樣的動做。

特徵：交付物或權的擁有者發生了「轉移」。

舉例：開發人員將測試版本交付給了測試人員。測試人員將正式版本交付給了運維人員。測試人員錯誤的將測試版本交付給了運維人員。IT團隊將系統交付給了業務部。某公司將軟件產品交付給了零售商。商店將軟件光盤交付給了用戶。此次只交付了一個模塊。

上線（Go-live / Ship）

定義：上到生成線，即部署到生產線上（生成環境中）

DoD：在生產環境中能夠看到，並可使用。

說明：上線後，可使用系統，也能夠不使用系統。若是使用系統，開始創造業務價值，那麼也叫投產（即投產=上線+使用系統）。若是上線後，不使用系統，那麼表示系統尚未「開工」，它並不影響上線這個動做。「使用系統」這個動做是上線後的下游活動，它不是「上線」活動的一部分。

特徵：必定是部署到生成環境中（不是其它環境），即生產線上。上線 = 在生產環境上的部署。

舉例：IT部門上線了一個演示版。正式版剛剛上線，尚未用戶訪問。某系統上線了半年，尚未投產，某系統剛上線1個月，公司業績就獲得了大幅提高。

發佈（Release）

定義：將集成（構建）出來那個總體（發佈對象），打上一個發佈標籤，提供出來，受衆能夠得到。

DoD：提供出來，受衆能夠獲取到。

說明：發佈的版本未必是正式版，好比發佈測試版（如Beta版）、試用版、演示版。發佈以後，受衆能夠得到軟件，但不必定就使用它。發佈的軟件能夠存儲在VCS（版本控制系統）中或製品庫中，也能夠存儲在光盤等介質上。受衆得到軟件以後的下游動做，不必定是部署，也多是其餘動做（如交付或其餘）。如：

發佈測試版-->部署到測試環境-->交付給測試人員作驗收測試。

發佈正式版-->部署到生產環境-->交付給用戶使用。

發佈正式版產品（如windows安裝盤）-->（售賣）交付給用戶 --> 部署 -->上線使用。

特徵：發佈物有（標籤）標識，提供出來能夠得到。

舉例：開發人員發佈了一個測試版。開發團隊在每月都會發佈一個演化版。某產品發佈了新的版本，用戶須要從新購買後，才能部署升級。某雲平臺發佈了新的版本，不須要用戶部署就可使用新的功能。本次版本發佈了，但沒有人使用。

按照以上的定義，那麼開頭的那段話，就能夠這樣來解讀，作出區分：

功能還沒集成進來 --> 功能尚未被合併到一塊兒，沒有造成一個總體。

功能還沒部署上去 --> 功能尚未安裝、配置到指定的環境中。

功能還沒交付 --> 功能尚未「轉移」給使用者。

功能還沒上線 --> 功能尚未部署在生成環境。

功能還沒發佈 --> 功能尚未提供出來，不能夠得到。

至於它們的依賴關係，即誰先誰後，除了集成是首先要完成的，其它幾個活動沒有固定的依賴關係，它們的前後順序須要根據具體的應用場景，例如：

場景1

某乙方公司爲甲方公司開發了一個web應用，需部署到生產環境，再發布給甲方公司，交付給使用部門（用戶），使用部門才能投產使用（上線），那麼它們的前後順序就是：

集成—>部署—>發佈—>交付—>上線。

場景2

A公司開發了一個商用軟件，發佈到網上，B公司經過購買得到，由A或B公司的技術員將軟件部署到B公司的生產環境，交給B公司的使用部門（用戶），使用部門才能投產使用（即上線），那麼它們的前後順序就是：

集成—>發佈—>部署—>交付—>上線。

場景3

早年，微軟發佈了Window XP（存儲在光盤中），交付給用戶，用戶再部署到生產環境，而後投產使用（上線）。如今的不少單體軟件，大多也是這樣的流程。那麼它們的前後順序就是：

集成—>發佈—>交付—>部署—>上線。

場景4

A公司開發了一個SaaS應用，部署到生產環境，交付給B公司，B公司再加入本身公司的基礎數據後上線了該SaaS應用，發佈給使用部門（用戶）使用，那麼它們的前後順序就是：

集成—>部署—>交付—>上線—>發佈。

還有更多場景，就不列舉了。

經過以上分析，你對「集成」、「部署」、「上線」、「交付」、「發佈」的概念的理解是否清晰了？若是還不清晰，請再讀一遍。

做者介紹：

王映紅：專一於軟件質量及過程改進的諮詢師和技術顧問，超過20年的IT行業經驗。是PMI組織認定的PMPer，國家信息系統項目管理師，TMMi Professional專家，持有ISTQB AM，Scrum敏捷教練CSP、CSM、CSD等認證，熟悉PMBOK、TMMi、TPS、DevOps、Scrum、Agile、Lean、ITSM、ITIL、COBIT、CMMI等領域知識。。