目前，軟件開發最大的變化是部署頻率。產品團隊更早（更頻繁）的將產品發佈到生產環境。數月或者數年的發佈週期變得越來越短-對那些構建純軟件產品的人來說更是如此。
現在，使用面向服務的架構和微服務方式，開發者可以設計模塊化的代碼庫。這允許他們同時在代碼庫中不同的地方編寫和部署代變更。
縮短部署週期的業務優勢狠明顯：
- 縮短上市時間
- 客戶可以在更短的時間內獲得產品價值
- 客戶的反饋也會更快的到達產品團隊，這意味着團隊可以更快的迭代特性和修復問題
- 開發人員的整體士氣會上升
但是，這種轉變也給運維或者DevOps 團隊帶來了新挑戰。更頻繁的部署，意味着已經部署的代碼會對站點可用性和客戶體驗帶來負面影響。這就是制定代碼部署策略如此重要的原因，因爲它可以最大限度的降低產品和客戶的風險。
在本文中，我們將討論不同的部署策略、最佳實踐和工具，讓你的團隊可以更快更可靠的工作。
現代應用的挑戰
現代應用通常是分佈式的，基於雲的。它們可以彈性擴展來滿足需求，基於高可用架構更好地容錯。這些應用可以使用全託管服務，例如AWS Lambda 和Elastic Container Service(ECS)等平臺處理一些運維責任。
這些應用經常頻繁部署。例如，移動app 和web 應用可能一個月內經歷多次更改。有些甚至一天多次部署到生產環境。
它們通常採用微服務架構，多個組件一起工作來提供完整的功能。不同的組件可以有不同的發佈週期，但它們全部無縫銜接在一起工作。
活動部分數量的增加，意味着出錯的機率增大。隨着多個開發團隊對代碼庫的修改，當問題發生時，很難定位到問題的根因是什麼。
另一個挑戰是基礎設施層的抽象，它們現在已經被當作代碼了。在部署新應用的時候，可能還需要部署新的基礎設施代碼。
常見部署策略
爲了應對這些挑戰，應用和基礎設施團隊應該設計和採用適合他們用例的部署策略。
這裏我們將回顧和討論不同部署策略的優缺點，以便你可以選擇合適的。
“大爆炸“部署
顧名思義，“大爆炸”部署一次性更新整個應用或者其中的大部分。這個策略可以回溯到軟件在物理介質上發佈並由客戶安裝的時代。
大爆炸部署要求企業在發佈之前進行廣泛的開發和測試，通常和大型有序發佈的“瀑布模型”有關。
現代應用不管是在客戶端還是服務端，都有定期自動更新的優勢。大爆炸的方式對於現代團隊來說，太慢，而且不敏捷。
大爆炸部署的特點包括：
- 所有的主要部件都打包在一個部署中；
- 用新的軟件版本整個替換現有的版本，或者替換大部分；
- 部署通常會導致長時間的開發和測試周期；
- 假定失敗的可能性很小，因爲回滾是不可能和不現實的；
- 完成時間通常需要很久，需要多個團隊的共同努力；
- 需要客戶採取措施來更新客戶端安裝。
大爆炸部署不適用於現代應用，因爲面向公衆的或者是關鍵業務應用無法接受這種風險，一旦中斷就意味着巨大的經濟損失。回滾通常耗時且代價巨大，甚至是不可能的。
大爆炸的方式適合非生產環境系統（例如，重新創建開發環境），或者是類似桌面應用這種供應商打包的解決方案。
滾動部署
滾動、階段性，或者是分步部署比大爆炸部署更好一些，因爲它們可以最大限度的降低相關風險，包括面向用戶的停機時間。
在滾動部署中，應用的新版本逐步替換舊版本。實際的部署發生在一段時間內。在此期間，新舊版本會共存，而不會影響功能和用戶體驗。這個過程可以更輕易的回滾和舊組件不兼容的任何新組件。
下圖顯示了該部署模式：舊版本顯示爲藍色，新版本顯示爲綠色，它們部署在集羣中的每一臺服務器上。
應用程序套件升級是一個滾動部署的典型例子。如果原始應用部署在容器中，升級可以一次處理一個容器。修改每個容器從應用供應商的站點上下載最新的鏡像。如果其中的一個應用存在兼容性問題，舊的鏡像可以重新創建這個容器。在這種情況下，套件的新舊版本應用可以共存，直到每個應用都更新完畢。
藍綠、紅黑、A/B 部署
這是另一個能自動防禦故障的流程。在這個方法中，兩個相同的生產環境並行工作。
一個是當前運行的生產環境，接收所有的用戶流量（稱之爲藍）。另一個是它的副本，但是閒置（稱之爲綠）。兩者使用相同的數據庫後端和應用配置：
應用的新版本部署在綠色版本環境中，進行功能和性能測試。一旦測試通過，應用的流量從藍色版本路由到綠色版本。然後綠色版本變成新的生產環境。
如果綠色版本激活後發現了問題，則將流量路由回到藍色版本中。
在藍綠部署中，兩個系統使用相同的持久化層和數據庫後端。保持應用的數據同步至關重要，鏡像數據庫可以幫助實現這一目標。
你可以使用藍色版本作爲主庫進行寫入操作，使用綠色版本作爲備庫進行讀操作。在從藍色版本切換到綠色版本時，數據庫會從主庫故障轉移到備庫。如果綠色版本在測試過程中需要寫數據，數據庫可以進行雙向複製。
一旦綠色版本被激活，你可以關閉或者是回收舊的藍色版本實例。你可以在這些實例上部署一個新版本，用作下次發佈的新的綠色版本。
藍綠部署依賴流量路由。這可以通過更新主機的DNS CNAMES 來完成。但是，TTL 太久會導致這些變更被延遲。或者，你可以改變負載均衡的配置，讓變更立即生效。類似ELB 的連接特性可以用來提供無縫連接。
金絲雀部署
金絲雀部署和藍綠有點像，但是它更加規避風險。你可以階段性的進行，而不用一次性從藍色版本切換到綠色版本。
採用金絲雀部署，你可以在生產環境的基礎設施中小範圍的部署新的應用代碼。一旦應用簽署發佈，只有少數用戶被路由到它。最大限度的降低影響。
如果沒有錯誤發生，新版本可以逐漸推廣到整個基礎設施。下圖示範了金絲雀部署：
金絲雀部署的主要挑戰是設計一種路由部分用戶到新應用的方法。此外，一些應用可能需要同類用戶進行測試，另一些應用可能每次都需要不同類型的用戶。
探索一些技術，來考慮路由新用戶的方法：
- 在允許外部用戶訪問之前，將內部用戶暴露給金絲雀部署；
- 基於源IP 範圍的路由；
- 在特定地理區域發佈應用；
- 使用應用程序邏輯爲特定用戶和羣體解鎖新特性。當應用爲其他用戶上線後，移除此邏輯。
部署最佳實踐
現代應用團隊可以遵循一些最佳實踐，來最大限度的降低部署風險：
- 使用部署清單。例如，清單上可能有一項是“在確保停止應用服務後，備份所有數據庫”，來防止數據損壞。
- 採用持續集成（CI）。CI 確保從代碼倉庫檢入的特性分支代碼，只會在經過一系列的依賴檢查，單元和集成測試，並且成功構建後，纔會合併到主幹分支。如果過程中出現錯誤，構建就會失敗，並通知應用團隊。所以使用CI 意味着應用的每次變更在部署之前都會進行測試。常見的CI 工具包括：CircleCI，Jenkins。
- 採用持續交付（CD）。使用CD 打包CI 構建的代碼產物，並隨時準備部署到一個或多個環境中。更多內容可以看看我們的Low-Risk Continuous Delivery eBook。
- 使用標準操作環境（SOEs）來確保環境一致性。你可以使用類似Vagrant 和Packer 這樣的工具來部署工作站和服務器。
- 使用自動化構建工具來自動化環境構建。使用這些工具，通常都是簡單的點擊一個按鈕，來銷燬整個基礎設施棧並從頭開始構建。CloudFormation 就是這種工具。
- 在目標服務器中使用類似Puppet、Chef和Ansible 這樣的配置管理工具，來自動應用OS 設置、打補丁和安裝軟件。
- 使用Slack 這樣的通信渠道來自動通知不成功的構建和應用故障。
- 創建一個程序，在部署失敗的時候向負責的團隊發送警告。理想情況下，你會在CI 環境中捕獲這些內容，但是如果變更已經部署了，你將需要一種方法來通知負責的團隊。
- 無論是因爲可用性還是錯誤率問題，對健康檢查失敗的部署啓用自動回滾。
部署後監控
即使你採用了所有的這些最佳實踐，事情仍然可能會失敗。因此，對部署後立即發生的問題進行監控，與規劃和執行完美的部署同樣重要。
應用性能監控（APM）工具可以幫助團隊監控關鍵性能指標，包括部署後的服務器響應時長。應用和系統架構的變更會極大的影響應用性能。
類似Rollbar 這樣的錯誤監控解決方案同樣重要。它會迅速通知團隊新部署或重新激活部署中的錯誤，這些部署可能會引發嚴重的bug，需要立即引起關注。
如果沒有錯誤監控工具，這些bug 可能永遠也不會被發現。雖然一些遇到bug 的用戶會花時間反饋，但大多數其他用戶不會這樣做。隨着時間推移，客戶的負面體驗會降低滿意度，甚至更糟糕的是，阻礙正在進行的業務交易。
錯誤監控工具還可以在運維/DevOps 團隊和開發者之間，共享所有部署後發生的問題。這些共享讓團隊變得更具有協作性，響應能力更強。