[譯] 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、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。