在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等領域知識，，
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/7239.html
標籤：其他
上一篇：商業分析BA:用戶故事怎么拆？