文章轉載自http://www.sel.zju.edu.cn/?p=224 浙江大學SEL實驗室 如有侵權，請聯系該賬號，侵權必刪除。
在生產中使用金絲雀部署來進行測試
根據Nolio發布的DevOps最佳實踐系列中的第一個demo，很多公司通過路由策略選擇性地對部分用戶發布新功能從而使用 “金絲雀部署（Canary Deployments）”來測試生產中的軟件，並將這一方式作為其可持續交付的一部分。“金絲雀部署”是增量發布的一種類型，它的執行方式是在原有軟件生產版本可用的情況下，同時部署一個新的版本。同時運行同一個軟件產品的多個版本需要軟件針對配置和完美自動化部署進行特別設計。
考慮到A/B測試和預防性（pre-emptive）性能測試，一旦克服了“金絲雀部署”所涉及的技術挑戰將可以減少部署流程中的風險。A/B 測試允許在不改變大多數用戶的用戶體驗的情況下進行對新功能的測試。而性能測試對於整個用戶群體來說同樣只會產生微不足道的影響。
根據Nolio的“金絲雀部署”，該方式由以下幾個步驟組成：
- 准備好部署各個階段的工件，包括：構建工件，測試腳本，配置文件和部署清單文件。
- 從負載均衡列表中移除掉“金絲雀”服務器。
- 升級“金絲雀”應用（排掉原有流量並進行部署）。
- 對應用進行自動化測試。
- 將“金絲雀”服務器重新添加到負載均衡列表中（連通性和健康檢查）。
- 如果“金絲雀”在線使用測試成功，升級剩余的其他服務器。（否則就回滾）
Nolio在他們的相關介紹中針對如何使用他們的產品對“金絲雀部署”進行高層次軟件編配做了概覽。他們使用了一個可在多個流程中復用的應用模型，並通過數據來驅動該模型的用途。管理和報表都將隨着“金絲雀部署”而被完成。
注釋：礦井中的金絲雀（canary in a coal mine） 17世紀，英國礦井工人發現，金絲雀對瓦斯這種氣體十分敏感。空氣中哪怕有極其微量的瓦斯，金絲雀也會停止歌唱；而當瓦斯含量超過一定限度時，雖然魯鈍的人類毫無察覺，金絲雀卻早已毒發身亡。當時在采礦設備相對簡陋的條件下，工人們每次下井都會帶上一只金絲雀作為“瓦斯檢測指標”，以便在危險狀況下緊急撤離。
所以，在BOSH部署CF某個版本release的過程中，對於部署了多個節點的組件，首先會經過離線、構建、配置和自動化測試之后才會重新通過NATS與現有系統相連，並更新其他節點。否則，這個版本的release將不會部署到其他節點上，Canary節點也會被回滾。