[譯] Deploy != Release（第一部分）：部署與釋出的區別，以及為什麼這很重要

• 原文地址：Deploy != Release (Part 1): The difference between deploy and release and why it matters.
• 原文作者：Art Gillespie
• 譯文出自：掘金翻譯計劃
• 本文永久連結：github.com/xitu/gold-m…
• 譯者：stormluke
• 校對者：MechanicianW、ALVINYEH

問：「最新版本部署了嗎？」

答：「我在生產環境裡部署了 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。

---

掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。