持續傳遞與持續部署的比較

這兩種自動化做法可加快將高品質程式碼傳遞給客戶的速度。

什麼是持續傳遞和持續部署?

除了持續整合外,持續傳遞及持續部署都是將軟體傳遞階段自動化的做法。 這些做法可讓開發小組以更快速、更準確和更有生產力的方式,將新功能、增強功能和修正程式發行給客戶。

持續傳遞和持續部署有許多共通點。若要了解這些做法之間的差異,並決定要實施哪一種,我們必須找出可以自動化的軟體傳遞階段。

將軟體傳遞流程自動化

取用者需要增加產品的個人化和安全性。為了符合這些需求,並更快速、可靠地傳遞軟體,開發小組可以採用 DevOps 文化。

DevOps 文化打破獨立專業領域的隔閡,並將人員、流程和技術整合在一起,以改進共同作業和協調性。因此,程式碼變更可快速進展到生產階段,客戶也可盡快獲得新的價值。

雖然開發、IT 運維、品質工程和安全性小組都依循 DevOps 文化緊密合作,但軟體傳遞流程仍然很複雜。DevOps 將軟體傳遞分成下列四個階段:規劃、開發、傳遞、部署和運維。

DevOps 中的軟體傳遞

若不採用自動化,開發小組必須手動建置、測試及部署軟體,包括:

  • 簽入、測試和驗證程式碼。
  • 將程式碼變更合併至主要分支。
  • 準備程式碼以上線。
  • 建立可部署的成品。
  • 將程式碼推送到生產環境。

自動化的階段

持續整合、持續傳遞及持續部署都是將開發和傳遞階段各個層面自動化的做法。每種做法都是從持續整合開始,然後進行下一步的自動化。

持續傳遞與持續部署的差異

持續整合

為了說明持續傳遞和持續部署,我們要先了解持續整合。採用持續整合時,「開發」階段 (建置和測試程式碼) 會完全自動化。每次您認可程式碼時,系統都會驗證變更並將其合併至主要分支,然後將程式碼封裝到組建成品中。

持續傳遞

持續傳遞可將下一個階段「傳遞」自動化。在採用持續傳遞的情況下,每當有新的組建成品可用時,系統就會自動將成品放在所需的環境中,並加以部署。

持續整合與持續傳遞 (CI/CD)

當小組同時實施持續整合和持續傳遞 (CI/CD) 時,開發和傳遞階段皆會自動進行。程式碼隨時都已準備好投入生產環境。所有小組只要手動觸發從開發轉換到部署的作業,讓自動化的組建成品用於自動部署即可,而這就像按下按鈕一樣簡單。

持續部署

透過持續部署,您可以將程式碼認可到生產環境的流程完全自動化。「開發」和「傳遞」階段之間會自動觸發,因此程式碼變更一收到驗證並通過所有測試後,就會即時推送。這表示客戶可以在改進功能可供使用時立即收到。

持續傳遞與持續部署:您應該選擇哪一個?

無論您採用持續傳遞還是持續開發,都可以找到支援的工具。

在您考慮要實施哪一種做法之前,請先判斷組織是否具備可支援這些做法的 DevOps 文化。接下來,由於 DevOps 小組致力於將整個軟體傳遞流程自動化,因此問題並不是「哪一種做法比較好?」 而是:「我們需要在持續整合與持續傳遞之間手動觸發嗎?」

當您尋找答案時,請使用下列問題來引導:

  • 可以在專案關係人未核准的情況下部署嗎?
  • 系統和管制需求允許端對端自動化嗎?
  • 可以一次向客戶公開一小部分的生產變更嗎?
  • 組織會快速回應生產錯誤嗎?

如果您的回答皆為是,建議您考慮進行持續部署,並將從程式碼認可到生產環境的軟體傳遞流程完全自動化。

如果您有任何一個回答為否,建議您從持續整合和持續傳遞 (CI/CD) 開始。 您要將已準備好投入生產環境的程式碼建立流程自動化,並一律只需手動核准部署。經過一段時間,您就可以開始進行持續部署,並將您的軟體傳遞流程完全自動化。

不論哪一種方式,每種做法都有下列共同優點:

  • 系統會自動建置、驗證和測試變更。
  • 程式碼一律可部署,因此完全不需要為發行日感到焦慮。
  • 發行時可得到更快速的專案關係人和客戶意見反應。
  • 降低開發人員的手動和系統管理工作,從而提高生產力。
  • 由於變更細微而且頻繁,因此不太會失敗,不穩定機率也降至最低。

持續整合、持續傳遞和持續部署的工具

DevOps 小組憑藉著工具鏈 (一系列相連接的軟體開發程式) 將軟體傳遞自動化。您要使用何種工具視您選擇的自動化做法,以及該做法要將哪些階段自動化而定。以下是一些範例。

在 Azure 中開始進行 DevOps

探索持續傳遞和持續開發工具,以及可在雲端中協助其他 DevOps 做法的工具。