什麼是連續部署？

連續部署 (CD) 是一個軟體發佈程序，使用自動化測試來驗證對程式碼庫的所有更改是否準確，然後準備好自主部署到生產環境中。近年來，此軟體發佈週期有很大的進展和進步。

CD 是一種軟體工程方法，透過自動化部署來供應軟體功能。

做為一個軟體發佈程序，CD 會自動測試及驗證新的程式碼，如果它們通過了自動化測試，便會將其推送到生產環境中。

連續部署是連續整合的延伸。連續整合可確保及時發現並修復錯誤，連續部署則透過自動推送這些程式碼更改，確保客戶始終都能擁有最新的軟體，亦即連續部署可讓您快速可靠地向客戶發佈更新。與傳統部署相反，連續部署應該在沒有任何人工干預的情況下進行。連續部署的主要目的是減少軟體變更的前置時間，並加快提供給最終使用者。

許多非常成功的軟體公司都實施連續部署，這是有充分理由的。當軟體開發人員將新程式碼行添加到現有軟體中時，便會透過一組自動化測試來驗證所做更改的功能性和穩健性。一旦程式碼通過自動化測試，就會自動將它提供給最終使用者。

之後，連續部署基礎架構將繼續監控軟體的行為反應。如果有任何錯誤行為發生，則自動機制會收回該項變更並將軟體恢復到原始狀態。所有這一切都是透過自動化系統進行，自動化測試、部署、監控和回收流程，都是連續部署管道的一部分。

為什麼科技公司採用連續部署？

連續部署可確保將新的功能或錯誤修復傳送給最終使用者。用於連續部署的強大基礎架構消除了測試和部署期間可能發生的手動錯誤，這也有助於提高軟體的品質，使公司能夠擴大他們的軟體產出。除了初始成本之外，從長遠來看，因為不需要昂貴的手動測試，也不會因延遲而造成損失，所以連續部署可以節省可觀資金。

連續部署的主要步驟是什麼？

通常，連續整合先於連續部署。開發人員完成一段程式碼後，先執行單元測試，再將其推送到連續整合管道中。之後構建（編譯）程式碼及其相依套件，並將這段新程式碼整合到現有的軟體系統中，連續部署管道便從此時開始。

第 1 步：測試和驗證

新程式碼的自動化測試是連續部署的關鍵步驟。自動化測試納入一組與即時使用案例非常相似的測試場景，測試套件會練習執行新的程式碼，並將其傳遞給所有這些使用案例，接著強大的自動化驗證系統不僅會測試新程式碼的功能性，還測試其他非功能性需求，例如性能、安全性和可用性。

自動化測試是為了確保新程式碼的行為符合預期，並且不會將新問題引入軟體（即產生迴歸問題）。一旦新程式碼通過所有自動化測試，它就會自動提供給最終使用者。然而，連續部署並沒有就此結束。

第 2 步：持續監控

在連續部署中，有一個系統會持續監控新程式碼在生產環境中的行為和表現，其實不僅是新程式碼，而是整個軟體系統都受到即時監控。如果新程式碼在生產環境中導致軟體出現問題，那麼強大的連續部署基礎架構便會觸發警報，包括觸發測試框架或通知程式碼所有者。這種監控和警報都是快速且即時發生的，因此可以快速進行任何必要的回收作業。

第 3 步：回收更改

強大的連續部署管道應該能夠快速、高效、持續地回應生產問題並從中恢復，這通常是透過自動撤回新的程式碼更改來完成，稱為回收更改。這種迅速恢復成軟體穩定版本的能力至關重要，因為最終使用者通常會積極使用該軟體，因此受影響程度很大。與此回收過程相關的重要指標是「平均恢復時間 (MTTR)」，它是指從偵測到失敗、到將軟體恢復至工作狀態所花費的時間，用來衡量連續部署系統的成熟度，MTTR 越高，造成業務損失的機會就越大。

連續部署的最佳實踐

測試驅動開發

在連續部署中，開發是以小塊程式碼的規模進行。亦即開發人員只處理一小部分功能，然後部署。當新功能/錯誤修復的規模較小時，很容易可以利用測試來推動開發。在編寫程式碼之前，應該先制定行為規範 (specs)，這些文件用來描述軟體在不同場景下的預期行為。基於此規範，開發人員就能制定單元測試計畫，使單元測試更加周嚴，並減少出現生產問題的機會。

無需手動部署

為了使連續部署系統成功，開發人員應避免手動構建、整合或部署程式碼。即使更改的內容似乎微不足道，但手動部署和即時編輯程式碼仍可能在連續部署管道中造成不一致。

強大的自動化測試框架

連續部署的關鍵組成之一便是自動化測試，此測試框架應該涵蓋所有可能的測試場景，應該足夠靈活以納入新的測試場景，應該一致地執行自動化測試，而且所有的測試資料和結果都應該抄入版本控制系統。自動化框架應該從頭到尾，都以零人工干預的方式進行。

連續部署的好處

縮短推出市場的時間

連續部署最顯著的優勢之一是，它可以幫助新的功能和修復快速觸及市場和客戶。在競爭日益激烈的環境中，上市時間是成功與否的關鍵指標。在測試程式碼、核准、最終發佈軟體給使用者方面，傳統的手動部署方法存在著相當長的延遲。

提高客戶滿意度

透過連續部署，軟體公司能夠快速回應客戶的意見回饋。此回饋可能是錯誤報告、或對新功能的請求，無論是什麼情況，只要公司開發出新功能或提供錯誤修復（通常使用連續整合），連續部署程序都能幫助它快速觸及客戶，從而提高客戶滿意度。

沒有重大失敗

在連續部署中，開發人員是逐漸添加新程式碼，以小塊規模不斷進行。在提交之前，開發人員會先測試這些更改並記錄結果。此外，還有一些系統會持續監控這些新變化，一旦回報有問題發生，便會立即恢復被更改的部分。在傳統的部署過程中，重要功能的發佈形式都是做為一個大的程式碼改版，很難從中查明問題根源。但是透過連續部署，公司問題能很快得到解決，發生重大失敗的情況也不那麼常見了。

提高勞動力的效率

連續部署可以將軟體開發中的大多數平凡任務自動化，因此開發人員無需擔心程式碼是如何整合、部署或測試的，工程師只需專注於提高他們的工作品質即可。它還有助於減少將新功能推向市場所需的時間，使開發人員可以快速完成一段程式碼並隨即部署，無需等待推出重大改版。

連續部署 vs. 連續開發

在連續部署中，從嵌入程式碼、到部署至生產環境的整個過程，每一步都是自動化執行。只有連續部署的最後一步，即部署至生產環境，是需要手動執行的。在連續部署中，直到最終核准投入生產的所有步驟都能予以自動化，但是，要使新程式碼進入生產環境，需要手動進行身份驗證/閘道通行證。簡而言之，連續部署是自動化的再進一步。

實施連續部署的挑戰

強大的連續整合框架

為了使連續部署順利運作，應該有一個堅如磐石的連續整合框架。其中包括用於連續簽入程式碼、自動構建和測試（手動或自動）的程序和工作流程，而且此程序必須足夠順暢且無失敗風險。建立這樣一個框架對許多公司來說都是一大挑戰，因此成功的連續整合同時需要開發人員、測試人員和構建工程師的支持。

建立強大的系統以實現連續整合，是需要花時間的，不要妄圖在一夜之間做出巨大改變。連續整合過程應該一步一步實施，確保所有員工保持同步。此外，對於在推動連續整合方面有模範表現的團隊，也應該給予獎勵。

人員和組織挑戰

連續部署提案可能會面臨員工、甚至客戶的抵觸，這是因為連續部署需要大量更改開發和測試流程，所以員工需要一些時間來建立對連續部署管道的信心。客戶的情況也是如此，客戶可能會堅持使用較不頻繁更新、但經過良好測試的版本，因為他們擔心連續部署可能會破壞某些功能。此外，從團隊到團隊，實施的成熟度可能也可能有所不同，一些團隊可能會虔誠地遵循連續部署範例，而有些團隊卻無法完全做到。

解決方法：對於每個利益相關者，找出他們在目前開發和部署過程中的痛點，然後，向他們解釋連續部署將如何緩解這些痛點。

工具和資源的可用性和成本

連續部署需要大量的工具和軟體才能順利運作，而購買和安裝這些工具可能成本高昂。市場上有許多用於連續部署的工具，但要弄清楚哪些工具有效、哪些工具無效，本身就是一大挑戰，而且某些工具可能與組織的現有系統不相容。此外，實施連續部署需要投入大量的資源，例如伺服器和運算能力。取得這些資源並在團隊之間共享它們可能會帶來其他挑戰。

解決方法：使軟體和工具在整個組織中隨時可用，舉辦培訓課程並幫助員工直覺地瞭解哪種工具適用於何處，選擇容易使用且較少手動配置的工具，建立共享連續部署資源的規則。