本文來自Rancher Labs
在之前關於CI/CD的文章中，我們簡單討論了藍綠部署和金絲雀發布以及它們在持續交付中所扮演的角色。這些都是十分有效的方法，能夠大大降低與應用程序部署相關的風險。所以，這篇文章我們來深入介紹藍綠部署和金絲雀發布。
藍綠部署和金絲雀發布通過讓IT人員可以在發布過程中發生問題時能夠還原到先前版本來減輕應用程序部署的風險。這兩個方法讓版本之間來回切換就像輕按開關一樣容易，並且可以自動執行，從而最大程度減少了用戶暴露在錯誤代碼的時間。在我們更進一步討論這兩種方法之前，讓我們先區分部署和發布。
如何將部署與發布解耦
雖然這兩個詞經常混淆使用，但實際上部署和發布是兩個獨立的過程。部署是指在特定環境（包括生產環境）安裝指定軟件版本的過程，更多是一種技術行為。它不一定必須與發布相關聯。而發布則是指向客戶群提供新功能，是一種業務決策。
傳統過程中，會在發布日期前一天部署好更新或是新功能，該更新或功能發布后可能會在媒體中廣泛傳播。眾所周知，在部署過程中可能會出錯，而因為發布時間與部署時間十分相近，因此幾乎沒有解決問題的空間。而如果將部署和發布解耦，那么在整個功能開發過程中頻繁進行生產部署可以降低IT部門的風險。那么，要實現部署和發布的解耦，需要代碼和架構能夠滿足新功能發布不需要變更應用程序的代碼。
什么是藍綠部署
在藍綠發布過程中，有兩套生產環境：藍環境和綠環境。藍色是當前版本並擁有實時流量，綠色是包含更新代碼的環境。無論任何時候，只有一套環境有實時流量。
要發布一個新版本，需要先將代碼部署到沒有流量的環境中，這是執行最終測試的地方。當IT人員確認應用程序已經准備就緒，就會將所有流量都將路由到綠色環境。那么綠色環境就已經生效，並且執行發布。
這是新代碼首次在生產負載（實際流量）進行測試。在實際發布代碼之前，風險仍然存在，並且永遠不會消失。但是，如果出現問題，IT部門可以快速將流量重新路由回藍色版本。因此，他們所要做的就是密切監控代碼行為，甚至可以使用適當的工具將其自動化，以查看綠色環境中的版本是否運行良好或是否需要回滾。
藍綠部署：無論何時，只有一套生產環境有實時流量
這種方法已經不是新方法了。IT部門總會創建一個新版本，然后將實時流量重新路由到該版本。而版本控制中通過組件編碼提供可靠性和可重復性是這一方法的亮點。
我們應該如何獲得可靠性和可重復性？開發人員將所有參數編入版本控制中，該版本控制是一個跟蹤所有代碼更改的系統，類似於數據庫。其中包括應用程序邏輯、構建過程、測試、部署過程、升級過程以及恢復過程等。總之，包含所有影響應用程序的因素。然后，計算機執行代碼，在相應的環境中部署應用程序，該環境與版本控制中編碼的exact state相匹配。
在DevOps出現之前，該流程通常是手動的，並且容易出錯。因為所有更改都只能記錄在文檔中，基於此，開發人員可以重新創建應用程序和環境。由於需要手動執行兩個關鍵步驟，因此此過程過於不可靠，從而導致頻繁出現問題。
雖然將應用程序和環境進行編碼也是一項需要手動進行的任務，但是它畢竟只是開發過程的一部分，而不是單獨的工作，例如創建文檔。在版本控制中編入了與生產環境相同的代碼。任何更改或更新都將自動觸發測試，以確保代碼處於可部署狀態。這樣，如果出現人為錯誤，系統也能夠很快發現它。
如何理解金絲雀發布（灰度發布）
與藍綠部署類似，金絲雀發布也是始於兩套環境：有實時流量的環境以及沒有實時流量但包含了更新的代碼的環境。與藍綠部署不同的是，流量是逐漸遷移到更新的代碼。一開始是1%，然后10%、25%，以此類推，直至100%。通過自動化發布，當確認代碼能夠正確運行時，它就可以逐步推廣到更大、更關鍵的環境中。如果在任何時候發生了問題，所有流量都會被回滾到之前的版本。這在很大程度上降低了風險，因為僅有一小部分用戶會使用到新的代碼。
IT不僅可以控制用戶部署的比例，而且金絲雀發布還可以從不太重要的用戶開始，例如使用免費賬戶的用戶或相對來說不太重要的業務市場。
金絲雀發布：實時流量逐漸從舊版本遷移到新版本直到更新生效
Cluster Immune System
Cluster Immune System可以讓金絲雀發布更進一步。它會連接到生產監控系統，當面向用戶的性能偏離預定義范圍（例如，錯誤率高出2%）時，將會自動回滾版本。這種方法可以識別通過自動測試難以發現的錯誤，並減少了檢測和響應性能下降所需的時間。
通過將發布與部署解耦並利用藍綠部署或金絲雀發布，風險將會顯著降低。在任何時候，IT都能夠將應用程序回滾到之前的版本——這已經與傳統的應用程序發布流程相去甚遠了。
新的技術和方法首次讓這一切成為可能：版本控制、作為代碼的基礎架構（Infrastructure as code）、容器和Kubernetes都能在這個嶄新的、靈活的、面向DevOps的IT世界中發揮着作用。