原文地址：http://ju.outofmemory.cn/entry/351873
翻譯自： Deploy != Release (Part 1): The difference between deploy and release and why it matters.
問：「最新版本部署了嗎？」
答：「我在生產環境里部署了 gif 動圖支持。」
問：「就是說 gif 動圖支持已經發布啦？」
答：「Gif 動圖的發布版本已經部署了。」
問：「……」
我曾在很多公司工作過，在這些公司中「部署（deploy，動詞）」、「部署物（deployment，名詞）」、「上線（ship）」和「發布（release）」都是隨意地使用，甚至可以互換使用。作為一個行業，我們在規范使用這些術語方面做得還不夠，盡管我們在過去的十多年里已經從根本上改進了運維實踐和工具。在 Turbine Labs 中，我們使用了「上線」、「部署」、「發布」和「回滾（rollback）」的精確定義，並花了大量的時間來思考當你把「發布」作為上線過程的一個獨立階段時，世界是什么樣子的。在這篇文章的第一部分，我會分享這些術語的定義，描述一些常見的「部署 == 發布」的實踐，並且解釋為什么這樣做的抗風險性很差。在第二部分，我會描述當「部署」和「發布」被視為軟件上線周期的不同階段時的一些非常強大的風險緩釋技術。
上線
上線 指你的團隊從源碼管理庫中獲取服務代碼某個 版本 的快照，並用它處理線上流量的過程。我認為整個上線過程由四個不同的專門的小流程組成：構建（build）、測試、部署和發布。得益於雲基礎架構、容器、編配框架的技術進步以及流程改進，如 twelve-factor 、 持續集成 和 持續交付 ，執行前三個流程（構建，測試和部署）從未如此簡單。
部署
部署 指你的團隊在生產環境的基礎設置中安裝新版本服務代碼的過程。當我們說新版軟件被 部署 時，我們的意思是它正在生產環境的基礎設施的某個地方運行。基礎設置可以是 AWS 上的一個新啟動的 EC2 實例，也可以是在數據中心的 Kubernetes 集群中的某個容器中運行的一個 Docker 容器。你軟件已成功啟動，通過了健康檢查，並且已准備好（像你希望的那樣！）來處理線上流量，但實際上可能沒有收到任何流量。這是一個重要的觀點，所以我會用 Medium 超棒的大引用格式來重復一遍：
部署不需要向用戶提供新版本的服務。
根據這個定義， 部署可以是幾乎零風險的活動 。誠然，在部署過程中可能會出現很多問題，但是如果一個容器靜默應對崩潰，並且沒有用戶獲得 500 狀態響應，那問題是否真的算是 發生 了？
部署了新的版本（紫色），但未發布。已知良好的版本（綠色）仍對線上請求做出響應。
發布
當我們說服務版本 發布 時，我們的意思是它負責服務線上流量。在動詞形式中， 發布 是將線上流量轉移到新版本的過程。鑒於這個定義，與上線新的二進制文件有關的所有風險 —— 服務中斷、憤怒的用戶、 The Register 中的刻薄內容 —— 與新軟件的發布而不是部署有關。在一些公司，我聽說這個上線階段被稱為 首次發布（rollout） 。這篇文章中我們將依舊使用 發布 來表述。
新版本發布，響應線上請求。
回滾
遲早，很可能不久之后，你的團隊就會上線一些功能有問題的服務。回滾（和它危險的、不可預測的、壓力山大的兄弟 —— 前滾 roll-forward）指將線上服務退回到某個已知狀態的過程，通常是重新發布最近的版本。將回滾視為另一個部署和發布流程有助於理解，唯一的區別是：
- 你正在上線的版本的特征在生產環境中已知
- 你正在時間壓力下執行部署和發布過程
- 你可能正向一個不同的環境中發布 —— 在上次失敗的發布之后某些東西可能改變了（或被改變了）
一個發布后回滾的例子。
現在我們已經就上線、部署、發布和回滾的定義達成了共識，讓我們來看看一些常見的部署和發布實踐。
原地發布（即部署 == 發布）
當你的團隊的上線流程涉及將新版本的軟件推送到運行舊版本的服務器上並重啟服務的流程時，你就是在原地發布。根據我們上面的定義，部署和發布是同時發生的：一旦新軟件開始運行（部署），它就會負載舊版本的所有線上流量（發布）。此時，成功的部署就是成功的發布，失敗的部署則會帶來部分或整體的服務中斷，一群憤怒的用戶，可能還有一個氣急敗壞的經理。
在我們所討論的部署/發布過程中，原地發布是唯一的將 部署風險 暴露給用戶的方式。如果你剛剛部署的新版本無法啟動 —— 可能是因為無法找到新增的環境變量而拋出異常，也可能是有一個庫依賴不滿足，或者只是你今天出門時沒看黃歷 —— 此時並沒有老版本的服務實例來負載用戶請求。你的服務此時至少是部分不可用的。
此外，如果有用戶相關的問題或更微妙的運維問題 —— 我把它叫做 發布風險 —— 原地發布會將線上請求暴露給你已發布的所有實例。
在集群環境中，您可能會首先原地發布一個實例。這種做法通常稱為 金絲雀 發布，它可以減輕一些風險 —— 面臨部署風險和發布風險的流量的百分比為：新服務實例的個數除以集群中的實例總數。
一個金絲雀發布：集群中的一個主機運行新版本
最后，回滾錯誤的原地部署可能會有問題。即使你回滾（重新發布）到舊版本，也無法保證可以恢復到以前的系統狀態。與當前錯誤的部署一樣，你的回滾部署在啟動時也可能會失敗。
盡管其風險管理相對較差 —— 即便使用金絲雀，一些用戶請求也會面臨部署風險 —— 原地部署仍舊是業務中常見的方式。我認為這類的經驗會導致不幸地混用「部署」和「發布」這兩個術語。
別絕望
我們可以做得更好！在 這篇文章的第二部分 ，我們會討論分離部署和發布的策略，以及可以在復雜的發布系統上構建的一些強大工作流。
我是 Turbine Labs 的一名工程師，我們正在構建 Houston ，這個服務可以輕松構建和監控復雜的實時發布工作流程。如果你想輕松地上線更多服務，你絕對應該 聯系我們 。我們很樂意與你交談。
感謝 Glen Sanford、Mark McBride、Emily Pinkerton、Brook Shelley、Sara 和 Jenn Gillespie 閱讀此文的草稿。
感謝 Glen D Sanford 。
翻譯自： Deploy != Release (Part 1): The difference between deploy and release and why it matters.
問：「最新版本部署了嗎？」
答：「我在生產環境里部署了 gif 動圖支持。」
問：「就是說 gif 動圖支持已經發布啦？」
答：「Gif 動圖的發布版本已經部署了。」
問：「……」