您已了解將「大規模部署」當作軟體傳遞模型的許多缺點，但知道什麼「不」適用只是成功的一半。 在這個單元中，你會學習這種單一方法的替代方案，以及它如何促進你提升可靠性的目標。
同時也值得區分兩個有時會互換使用的相關術語：
-
持續交付：每一項通過自動化測試的變更都 已準備好 部署到生產環境，但實際發布到生產環境則需人工審核。
-
持續部署：所有通過自動化測試的變更都會 自動 釋出到生產環境，無需手動門檻。
兩者都依賴相同的基礎（頻繁整合、自動化測試、可重複的流程）。 本單元聚焦於這些共同的基礎。
什麼是持續傳遞？
持續交付 是一種方法，能讓每一次程式碼變更都能以更快、更輕鬆、更低風險且更具重現性的方式釋 出 。 持續交付不再讓每次軟體部署或更新都成為史詩級事件，而是將其變成快速、例行且可預測的隨需體驗。
部署頻率：使用持續傳遞模型時，部署通常會發生。 節奏可以是每月、每週、每日，甚至每小時。 關鍵在於您會「更頻繁地部署更小且更聚焦的變更」。
由程式碼提交觸發：交付流程從程式碼提交開始，不再等待提前排定的發佈窗口。 此程式碼可以是軟體、基礎結構，或甚至是像軟體設定之類的項目。 每一項變更都會被建置、測試，並隨時準備發布。 根據貴組織的控管措施，推送到生產環境可能仍需在核准後進行。
自動化測試：您不僅可以使用整合式自動化測試來測試程序代碼，還可以提供這些測試結果的快速意見反應。 正是此快速意見反應，讓您能夠快速逐一查看失敗的測試並從中復原。
一旦程式碼經過測試之後，您就可以在一系列預備環境 (例如測試、QA 等) 中測試端對端部署。 透過這些環境推出部署，會成為部署體驗中不可或缺的一部分。
歷程記錄：您不僅想要部署活動的歷程記錄，也想要隨時協調生產環境。 您想要了解哪個部署建立了目前的實際執行環境。 有了此知識，即可追蹤設定、測試結果及程式碼本身之類的項目，一直追蹤回到觸發部署的個別提取要求。
部署目標
既然你已經了解持續交付的運作方式，請考慮持續交付及其他 DevOps 實務在部署軟體解決方案時幫助你達成的目標。
目標 1：降低部署服務所造成的壓力，同時提高那些服務的可靠性
減輕軟體與基礎設施部署的壓力，能提升執行這些專案的工程師的日常體驗。 隨之而來的可靠性提升也有利於終端用戶，因為他們會遇到較少的停機與中斷。
目標 2：縮短從得知需要變更，到將該變更部署至實際執行環境之間的時間間隔
舉例來說，假設你發現了一個影響營收的程式碼缺陷，並且你知道該如何修正它。 有了成熟的 DevOps 實務，從承諾到生產的路徑既短又可預測。 變更會被建置、自動在相關環境中測試，並在幾分鐘內準備好發布。 一旦獲得所需批准，該作品即可升級為量產，而不必等待未來的發行窗口。
目標三：縮短從有想法到交付可用軟體的時間
這個目標與前一個類似，但著重於創新而非修正。 你大概需要多久才能付諸行動一個新想法？ 透過這種部署模式，你可以放心將新概念整合進生產系統，且不會破壞或阻礙現有系統。 這種自信讓你能快速推出新功能。
部署結果
本單元討論的目標不僅是理論上的抱負，而是可衡量的。 自 2014 年起，DevOps 研究與評估（DORA）團隊每年發布軟體交付效能的 DevOps 現況研究報告。 近年來，這項工作已以 《加速 DevOps 現況報告》的形式發表。 目前的DORA模型追蹤五項交付指標：
- 部署頻率
- 變更交期
- 變更失敗率
- 部署失敗後的復原時間
- 部署返工率
研究年復一年顯示，表現較佳的團隊能更頻繁地交付變更，更快從提交階段進入生產環境，較早從部署失敗中恢復，且花費較少時間修復部署相關問題。 欲了解最新研究與指標定義，請參閱 DORA 的軟體交付指標。
這些結果證實了部署實務的重要性。