應用部署是一個將軟體提供給使用者的過程，通常包含配置環境、安裝及測試等步驟。現如今，大部分企業在部署新的應用程式時，會至少自動化其中一些步驟。應用程式部署的策略會影響該應用的效能、穩定性以及執行速度，因此有時會在向所有人提供更新之前，先對一小部分使用者進行測試。
軟體開發和使用者體驗的現代標準要求開發人員持續地更新他們的專案。部署和整合已經成為日常操作——一個現代的應用程式每天都需要部署。這就是為什麼現在擁有一個有效的部署技術比以往任何時候都更重要。
當下，企業追求更為靈活和可擴充套件的系統，因此微服務架構、雲基礎設施變得隨處可見。靈活的架構意味著諸多開發團隊會牽涉其中，這會給部署帶來挑戰。
本文將介紹應用部署過程的幾個主要階段以及不同的應用部署模式。
應用部署的主要階段
前期準備/計劃階段
在計劃準備階段，以下步驟十分重要：
-
確認協作方： 軟體開發的過程中會涉及到不同的團隊。部署前應該告知所有協作方，以儘量減少開發、運維和安全團隊之間的摩擦。
-
列出第三方工具： 確定部署流程中所需要的所有工具以及要求，這可以幫助你確保所有協作方都知道如何有效地使用它們並且最大限度地減少問題的產生。
-
設定測試環境： 在正式釋出新產品前，一定要測試軟體
-
設計清晰的部署步驟： 與團隊密切溝通以確保部署流程清晰明瞭
-
建立回滾計劃： 如果新版本出現嚴重的問題可以啟用這一計劃。漸進式交付策略讓無縫自動回滾部署成為可能。
-
設定效能監控指標： 常用的指標有記憶體、CPU使用率以及查詢響應時間。你可以使用這些基本指標和自定義KPI來衡量部署的有效性。在漸進式交付中，你甚至可以使用這些指標來自動確定部署是否成功。
測試階段
測試階段可以在部署之前驗證軟體是否可靠。在這一階段中，需要考慮以下方面：
-
編寫單元測試： 其目的是測試軟體的其中某個部分，以驗證其獨立於其他部分的行為是否可以正常執行。當結果與需求一致時，單元測試透過，否則失敗。
-
在CI流程中整合測試： 將單元測試整合到共享程式碼倉庫中以自動化構建和驗證每個部分。在部署之前完成這個步驟可以更輕鬆地修復和移除bug。
-
在staging環境中部署測試： 模擬生產環境，並使用它來測試更新、程式碼及其他方面，以確保軟體按預期執行。
-
執行端到端的測試： 從頭到尾測試應用程式的工作流程，過一遍它可以執行的操作，檢查它是否可以與其他元件（如網路連線、硬體等）一起正常執行。
-
驗收測試： 這是測試流程的最後一步，需要與相關方或真實使用者一起驗證軟體。他們的反饋可以幫助決定軟體是否生產就緒。
-
冒煙測試： 建立一個專門的測試套件，在部署之後在生產中執行，以驗證剛剛釋出的軟體沒有缺陷。
部署及釋出階段
應用部署的最終階段，包括以下方面：
-
部署到生產環境： 將更新推送到生產環境中，使用者可以使用它們。
-
監控產品效能： 根據KPI來監測產品的效能，檢查HTTP errors和資料庫效能等。
-
監控環境健康： 藉助監控工具來識別軟體環境相關的潛在問題，比如作業系統、資料庫系統以及編譯器等。
-
執行自動化回滾： 藉助冒煙測試和指標來衡量釋出是否成功並且當存在問題時自動回滾到上一個版本。
-
跟蹤日誌： 藉助日誌獲得軟體執行的可見性，比如瞭解軟體如何執行在基礎設施上，如何調查錯誤並識別潛在的安全風險。
-
記錄釋出的版本和註釋： 儲存對產品進行修改時建立的新版本的副本，這有助於保持一致性。
應用部署模式
金絲雀釋出
金絲雀釋出可以逐一發布新特性，而非完整的更新版本。開發人員讓舊版本處於活躍狀態，並比較更新前後的例項效能。此外，金絲雀釋出會先將新功能提供給一小部分使用者使用，根據小範圍的使用者反饋對產品進行必要的調整。
以下是金絲雀釋出的基本步驟：
-
開發人員上傳新版本（假設其為Version B）到伺服器。
-
主要使用者群體依舊定向到 Version A，與此同時，小部分使用者開始使用 Version B，進而開發人員可以監控新版本的效能並進行改進。
-
對 Version B 進行必要的調整之後，開發人員就會將大部分流量定向到更新完畢的例項中。此時團隊開始測量效能並將其與舊版本進行對比。
-
當 Version B 已經足夠穩定，開發人員就會切斷 Version A 並將流量完全重定向到更新後的程式碼庫中。
要保證金絲雀釋出的成功，開發人員必須設定清晰的效能指標，原始版本和金絲雀版本（更新版本）應該同時在相同的條件下部署，以更客觀地進行分析。
金絲雀釋出的優勢之一是可以最大限度地減少當機時間並且避免新版本中存在潛在的問題。 此外，透過在小部分使用者中測試特性，開發人員可以在對更多使用者產生影響之前發現並修復問題，這有助於確保新功能或更新不會對使用者體驗產生負面影響。
這種部署模式也存在缺陷——十分耗時。金絲雀的測試和部署是分幾個階段進行的，需要時間進行徹底的監控和評估。正因為如此，不是所有使用者都能馬上從新的功能和升級中受益。
正如許多同時執行兩個版本的部署策略一樣，開發人員需要牢記並確保技術棧和資料庫的相容性。
藍/綠部署
藍/綠部署是指同時部署兩個應用版本，當前版本（藍）和新版本（綠）在不同的環境中執行，並且只有一個版本是實時執行的。當綠版本進行測試時，藍版本繼續執行，反之亦然。兩個版本都可以處於活躍狀態，但只有一個是公開的（通常是藍版本）。
當測試完成、新部署就緒，就可以安全地切換流量到綠版本。此後，藍環境可以保留下來以執行回滾操作或在未來的更新中使用此前的功能。
藍/綠部署幾乎消除了當機時間並允許即時回滾。 藍/綠環境的隔離可以保護實時部署在測試階段免受 bug 的影響。雖然這種部署策略的風險較低，但實施成本較高，因為必須覆蓋兩個環境進行操作，會增加儲存空間、計算能力及硬體等成本。為了在藍綠環境之間無縫切換，開發團隊還需要保證資料格式和儲存的相容性。
滾動部署
使用滾動部署，開發人員可以同時上傳幾個版本——活躍的版本數量被稱為視窗大小（window size）。開發者可以1次只上傳1個例項（即視窗大小設定為1）或在叢集中同步更新部署應用程式。為了更快且更安全地部署，開發人員常常使用容器技術。容器應用部署包括 Docker 和 Kubernetes，它們是隔離更新版本、啟用和禁用服務以及跟蹤變化的常用工具。
滾動部署提供了靈活性，並減少了停機時間，因為它只在新版本準備好之後再將流量重定向到新版本。 同時，它也降低了部署風險，因為更新存在的缺陷隻影響到有限的使用者。但是這一部署方法回滾速度較慢，因為它需要一個漸進的方法。
另外，新的部署必須向下相容，因為它們需要與舊版本共存。如果應用程式需要會話持續存在，那麼確保負載均衡支援粘性會話也十分重要。
影子（Shadow）部署
影子部署包含兩個活躍的平行版本，將傳入請求 fork 到當前版本，然後將它們傳送到新版本。這種方法有助於測試新功能如何在不影響流量的情況下處理生產負載。當新版本滿足效能和穩定性要求後，即可安全上線應用。
雖然這種模式十分專業，設定起來也複雜，但它消除了對生產的影響，利用流量複製來測試使用影子資料的bug。測試結果是高度準確的，因為它們使用生產負載來建立模擬現實條件。影子部署被認為是一種低風險的方法，並經常與其他方法相結合，比如金絲雀部署。
執行影子部署的步驟：
-
應用層級的實現： 開發人員編寫的函式既可以嚮應用程式的當前版本也可以向新版本傳送輸入。輸入和輸出可以同時處理，也可以在一個佇列中非同步處理，以獲得更高的精度。團隊可以選擇在客戶端劃分輸入，在瀏覽器或移動裝置中設定不同的API目標。
-
基礎設施層級的實現： 開發人員配置負載均衡以 fork 格式以及支援兩個版本的端點。開發人員需要確保沒有重複，應用程式絕不能兩次請求相同的資料。新版本應該從第一版本中接收使用者的資訊，否則，使用者將不得不重複輸入支付或註冊資料。
-
影子模式結果評估： 團隊需要注意資料的錯誤，比較兩個版本的效能，檢查新版本能否正確接收舊版本的輸入。