最後幾篇繼續提一些軟體發行部署的測試右移策略與實際應用。

部署(Deployment)，意思是把軟體發布並上線到一個運行環境中的動作。

如果部署到測試環境，那你就會有一個測試版本的軟體在測試環境中跑著

如果是部署到正式環境上的話，客戶就可以到正式環境中去使用你的正式版產品。

而當軟體開發已經到了正式環境上的部署階段時，基本上開發跟測試都已經完成

但是對軟體維運而言，不可能有上線完全沒問題的狀態，

問題只會有大有小，與可以控制跟不可控制

所以在部署階段也是有很多策略可以去控制風險，以下介紹一些常見的軟體部署方法：

——

藍綠部署 (Blue/Green Deployment)

藍綠部署的意思是藉由維護兩套環境，來運行新舊不同版本的正式環境

一個環境是正在使用的環境(Active)，另一個則是備用的環境(Inactive)

正式版軟體做升級的時候，只需要利用Router或是Load Balancer等服務來做無痛切換

如果出問題的話也可以快速切回舊的環境，對回滾的策略來說非常有效

優點就是沒有停機時間，同時只會有一個環境會在線上，部署出問題的風險小。

但問題就是對伺服器的花費跟維運工作量就是兩倍，甚至是兩倍以上

以大型的專案或是軟體服務來說可能不會是一個經濟實惠的做法。

另外如果是有傳統架構跟微服務混合的軟體架構來講，藍綠部署也會不好做

原因是傳統架構的伺服器分工可能沒切得這麼開，可能還是會需要停機維護。

——

金絲雀部署 (Canary Deployment)

金絲雀部署跟藍綠部署不同，藍綠部署是非黑即白的兩套環境，

而金絲雀部署又叫做灰度部署，也被稱為階段部署(Phase Deployment)

這種作法是先把新版本部署給一小部分的使用者，驗證沒問題之後再繼續慢慢部署

直到部署給所有使用者已完成升級，以降低新版本造成的不確定風險與潛在的不良影響

—

金絲雀部署有個這樣的典故：17世紀的英國礦坑工人在下礦坑的時候，

隨隊都會帶一隻金絲雀，原因是金絲雀這種鳥類對瓦斯氣體非常敏感

空氣中只要有一點點微量的瓦斯，金絲雀就會馬上知道並停止啾啾叫

而如果礦坑空氣中的瓦斯含量太高，金絲雀也會比人類更早毒發身亡

礦工會帶著金絲雀當作「瓦斯檢測的指標」，遇到危險就會迅速撤離。

—

而金絲雀部署，也是想利用階段性部署的策略，提早發現問題以確保整體軟體發佈的品質。

以現在主流DevOps小步快跑的快速迭代做法，蠻符合金絲雀Fix-forward持續更新的精神

所以像是平常大家在使用的Facebook、IG、YouTube這種大的軟體公司

有時候你會發現自己的介面跟朋友的不太一樣，系統上也常會發現不一樣的版本更新

這種作法就是類似金絲雀部署的實際應用。

——

AB部署 (A/B Deployment)

AB部署跟平常常聽到的AB Testing非常類似

也就是藉由在同一個生產環境上，對兩群使用者部署不同的版本來做不同面向的測試。

目的是想找出在測試環境中無法驗證的整合問題，像是負載量等需要正式環境資料的驗證

一般來說AB部署都是比較短時間，然後有明確測試目的的部署策略

在測試完畢、目的達成之後，就會把環境恢復正常。

——

以上所描述的是server端常用的一些部署策略

而client端的部署策略，會因為產品間的差異性，差距會更大一點

下篇來聊聊我自己在Windows application上面的部署優化經驗。