[譯] 部署 != 發佈 (第二部分)

• 原文地址：Deploy != Release (Part 2)
• 原文做者：Art Gillespie
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者： lwjcjmx123
• 校對者：LeviDing

將部署和發佈解耦以下降風險，並解鎖功能強大的工做流

在這系列的第一部分，我解釋了咱們在 Turbine Labs 上用於上線、部署、發佈和回滾的定義。我解釋了部署風險和發佈風險之間的差別。並且我還談到了本地發佈 —— 一種經常使用的用於將生產請求暴露給部署風險的部署/發佈策略。本文中，我將討論解耦部署風險與發佈風險的方法，並簡單介紹一些功能強大的工做流來管理髮布風險。

藍/綠部署（或部署!=發佈）

藍/綠部署涉及到在生產環境已有發佈版本的同時部署新版本。你能夠爲每種「顏色」使用專用硬件或虛擬機，並在它們之間交替進行後續部署，也可使用容器或像 Kubernetes 這樣的容器集羣來管理臨時進程。不管如何，關鍵在於一旦部署了新的（綠色）版本，它不會當即就被髮布 —— 也不會響應生產請求。這些服務仍由目前運行良好的（藍色）版本處理。

在藍/綠部署體系中，發佈一般會涉及到更改負載均衡，在添加新版本的主機以後，移除掉之前運行良好的舊版本。儘管這種方式要比本地部署好的多，它也會有一些侷限性，尤爲是在發佈風險方面。回到正題。首先，咱們能夠看到你能夠作到不少很是強大的事情，經過不一樣的步驟在部署和發佈的時候

什麼都沒有

若是你的部署在循環崩潰回退中掛起，或這由於數據庫密鑰錯誤且新部署的服務沒法鏈接，你也不用承受必需要作些什麼事情來挽救的壓力。你的團隊能夠在沒有任何壓力的狀況下診斷問題或構建另外一個新版本，而後進行部署這個新版本。你能夠很輕鬆的重複嘗試，直到你部署的版本再也不出現問題。與此同時,線上的已發佈 版本還在照常響應生產環境的請求,而且你沒必要再公司博客上發佈此次部署失敗了的通知,換句話說,*你的部署風險基本都被掩蓋了

健康檢查和集成測試

當部署與發佈被拆分時，你能夠在任何生產環境流量暴露給它以前，針對新部署的版本運行自動化健康檢查和集成測試。我參與過許多過後分析，其中最重要的一點是，在部署好後或者預發佈的時候進行健康檢查等簡單的事情能夠有效避免問題暴露在用戶面前。

藍/綠部署在健康檢查和集成測試的時候。若是 v1.2 出現問題，客戶將不會發現這些問題。

更細粒度的暴露發佈風險

因爲在引入新的「綠色」主機時，你不必定須要替換現有的「藍色」主機，因此你能夠有一些方法來控制新版本生成流量的百分比。例如，若是你有三臺運行已知良好的服務版本，你能夠在負載均衡器中再混入一臺「綠色」主機。如今新版本只有 25% 的流量，而不是33%，只要你不是採用替換原有「藍色」主機的狀況下。雖然這仍然是至關粗放的版本風險管理，但總比沒有好。

當你使一個「綠色」主機可用時，暴露該版本中任何錯誤流量的百分比則取決於主機的總數。這裏是 33%。

持續發佈

正如我以上的討論，從部署風險角度看，藍/綠部署更好。但當咱們考慮發佈風險時，典型的藍/綠設置處理版本的方式並不能爲咱們提供咱們正在尋找的細粒度控制。若是咱們贊成生產中的每一個發佈都是測試（無論贊成與否，它一直如此），而咱們真正想要的是使用模式匹配規則來分割咱們的生產請求，並動態分配任意百分比的流量到咱們服務的任何版本。這是一個強大的概念，它是構成複雜發佈工做流的基礎，如內部測試、增量發佈、版本回退和黑暗流量。每篇文章都分爲上下兩部分（即將推出！），但我在這裏會大概的介紹一下他們。

內部測試是僅向員工發佈新版本服務的流行技術。經過強大的發佈服務，你能夠編寫諸如「將內部員工流量的 50% 發送到版本爲 x.x 實例」的規則。在個人職業生涯中，生產中的內部測試捕獲到了許多我羞於認可的使人尷尬的錯誤。

增量發佈是一個過程，從發送一些小百分比生產請求到新版本服務開始，同時監視這些請求的性能 —— 錯誤、延遲、成功率等 —— 與以前的產品版本相比而言。當你確信新版本不會出現任何相對上一版本意外行爲的時候，你能夠增長百分比並重複此過程，直至到達 100%。

回滾是在使用持續性發布系統的時候，將生產中的請求轉發到最後一個運行良好的實例。它速度快、風險低，而且像發佈自己同樣，能夠經過細粒度方式有針對地完成。

黑暗流量是一種功能強大的技術。你發佈的系統會複製生產請求，並將一個副本發送到你的服務運行良好的「明面」上的版本，另外一個發送到新的「暗處」的版本。暴露在「明面」的版本負責實際響應用戶請求。「暗處」的版本也會處理請求，但其響應會被忽略。當您須要在生產環境下測試新軟件時，這很是有效。

在 Turbine Labs 中，咱們使用本身的產品 Houston 來完成內部測試，增量發佈、回滾，並很快進行黑暗流量。對我來講，像 Houston 這樣先進的發佈系統對個人平常工做來講是一種革命性改變。如此輕量級、低風險的發佈，使得我能夠常常這樣作。做爲一個團隊，它以我沒有預料到的方式提升了咱們的功能發佈速度和產品質量。咱們將在之後的文章中更詳細地介紹咱們在 Turbine Labs 的內部發布流程。

結論

在過去的五年中，軟件發佈領域的大部分技術和流程進展 —— 雲計算、容器、編排框架、持續交付等 —— 都集中在部署上。有了這些進步，爲你的服務設計和實現一個健壯的部署流程變得垂手可得，但設計和實現一個能夠支持你服務需求的可靠發佈流程仍然十分困難。Facebook、Twitter 和 Google 致力於設計、實現和持續維護像 Gatekeeper、TFE 和 GFE 這樣成熟的發佈系統。這些系統不只在服務可靠性方面屢次證實了它們的價值，還包括開發者生產、產品速度和用戶體驗方面。

一個先進的發佈系統不只能夠下降部署風險，還能夠直接提升產品速度和用戶體驗。

咱們開始關注爲各類規模的公司提供的便利的產品（Houston、LaunchDarkly）和開源工具（Envoy、Linkerd、Traefik、Istio），以及最近才向大型公司提供的發佈單元和工做流。這些產品和工具使得人們能夠更快速地發佈功能，而且使咱們有信心不會對用戶體驗產生負面影響。

我是 Turbine Labs 的一名工程師，咱們正在構建 Houston —— 一項使構建和監控複雜的實時發佈工做流程變得很是簡單的服務。若是你但願交付更多產品而且花更少的心思，那麼你絕對應該聯繫咱們！咱們很樂意與你交流。

感謝 Glen Sanford、Mark McBride、Emily Pinkerton、Brook Shelley、Sara 和 Jenn Gillespie 閱讀本文的初稿並提出修改意見。

---

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