金絲雀發布
2014 年 6 月 25 日
金絲雀發布是一種降低在生產環境中導入新軟體版本風險的技術,透過將變更緩慢推展到少數使用者,再推展到整個基礎架構並讓所有人使用,來達到此目的。
類似於 藍綠部署,您會先將新版本的軟體部署到基礎架構的子集,且不將任何使用者路由到該子集。
當您對新版本感到滿意時,可以開始將一些選定的使用者路由到該版本。有不同的策略可供選擇,決定哪些使用者會看到新版本:一個簡單的策略是使用隨機樣本;有些公司會選擇在向全世界發布之前,先向其內部使用者和員工發布新版本;另一種更精密的做法是根據使用者的個人資料和其他人口統計資料來選擇使用者。
當您對新版本更有信心時,可以開始將其發布到基礎架構中的更多伺服器,並將更多使用者路由到該版本。推出新版本的良好做法是使用 Phoenix 伺服器 重新利用現有的基礎架構,或使用 不可變伺服器 提供新的基礎架構並停用舊的基礎架構。
金絲雀發布是 平行變更 的應用,其中遷移階段會持續到所有使用者都已路由到新版本。在那個時間點,您可以停用舊的基礎架構。如果您發現新版本有任何問題,還原策略就是將使用者重新路由回舊版本,直到您修復問題為止。
使用金絲雀發布的好處是能夠在生產環境中對新版本進行容量測試,並在發現問題時採用安全的還原策略。透過緩慢增加負載,您可以監控並擷取度量資料,了解新版本如何影響生產環境。這是一種建立完全獨立的容量測試環境的替代方法,因為該環境將會盡可能類似於生產環境。
雖然此技術的名稱可能不熟悉 [1],但金絲雀發布的做法已經採用了一段時間。有時它會被稱為分階段推出或增量推出。
在大型分散式場景中,除了使用路由器來決定將哪些使用者重新導向到新版本之外,使用不同的分區策略也很常見。例如:如果您有地理上分散的使用者,您可以先將新版本推廣到一個區域或特定位置;如果您有多個品牌,您可以先推廣到單一品牌,等等。Facebook 選擇使用多個金絲雀的策略,第一個金絲雀僅對其內部員工可見,並啟用所有 功能旗標,以便他們可以及早偵測到新功能的問題。
由於技術實作的相似性,金絲雀版本可以作為實作 A/B 測試的一種方式。但是,最好避免混淆這兩個問題:雖然金絲雀版本是一種偵測問題和回歸的好方法,但 A/B 測試是一種使用變異實作來測試假設的方法。如果您監控業務指標以使用金絲雀偵測回歸 [2],同時也將其用於 A/B 測試可能會干擾結果。更實際地說,從 A/B 測試中收集足夠的資料以證明統計顯著性可能需要數天,而您希望金絲雀版本在幾分鐘或幾小時內完成。
使用金絲雀版本的一個缺點是您必須同時管理多個軟體版本。您甚至可以決定同時在生產環境中執行兩個以上的版本,但最好將同時執行的版本數量減至最少。
使用金絲雀版本困難的另一個場景是當您分發安裝在使用者電腦或行動裝置中的軟體時。在這種情況下,您對新版本升級發生的時間點控制較少。如果分發的軟體與後端通訊,您可以使用 平行變更 來支援兩個版本,並監控正在使用的客戶端版本。一旦使用量降至某個等級,您就可以將後端收縮為僅支援新版本。
執行金絲雀發布時,也需要留意資料庫變更的管理。同樣地,使用 平行變更 是一種減輕此問題的技術。它允許資料庫在推出階段支援應用程式的兩個版本。
進一步閱讀
金絲雀發布由 Jez Humble 和 Dave Farley 在 持續交付 一書中描述。
在 此演講 中,Chuck Rossi 更詳細地描述了 Facebook 的發布流程以及他們如何使用金絲雀發布。
致謝
感謝許多 Thoughtworks 同事提供回饋:Jez Humble、Rohith Rajagopal、Charles Haynes、Andrew Maddison、Mark Taylor、Sunit Parekh 和 Sam Newman。
備註
1: 此技術的名稱源自礦工,他們會帶著一隻關在籠子裡的金絲雀進入煤礦。如果毒氣洩漏到礦坑中,金絲雀會在礦工之前死亡。金絲雀發布提供了類似的早期警示形式,用於在問題影響到整個生產基礎架構或使用者群組之前發出警示。
2: 監控業務指標並在統計上顯著的回歸時自動回滾發布的技術稱為叢集免疫系統,由 IMVU 開創。他們在 部落格文章 中描述了此方法和其他實務,作為其持續部署方法的一部分。