持續傳遞部署模型
- 4 分鐘
您已了解將「大規模部署」當作軟體傳遞模型的許多缺點，但知道什麼「不」適用只是成功的一半。 在此單元中，您將了解該整合型方法的替代方法，以及其如何讓改善可靠性的目標更上層樓。
什麼是持續傳遞？
「持續傳遞」是一種方法，讓您可以透過該方法，以更快速、更輕鬆、更低風險且更能重現的方式，讓軟體變更可供使用。 持續傳遞無法讓每個軟體部署或更新成為史詩級事件，而是致力於將其轉換成可依需求發生的快速、例行性且可預測的體驗。
部署頻率：使用持續傳遞模型時，部署通常會發生。 這通常可能是每月、每週、每日，甚至是每小時。 關鍵在於您會「更頻繁地部署更小且更聚焦的變更」。
由程式碼提交起始：部署會在提交程式碼時發生，而不是提前很久排程。 此程式碼可以是軟體、基礎結構，或甚至是像軟體設定之類的項目。
自動化測試：您不僅可以使用整合式自動化測試來測試程序代碼，還可以提供這些測試結果的快速意見反應。 正是此快速意見反應，讓您能夠快速逐一查看失敗的測試並從中復原。
一旦程式碼經過測試之後，您就可以在一系列預備環境 (例如測試、QA 等) 中測試端對端部署。 透過這些環境推出部署，會成為部署體驗中不可或缺的一部分。
歷程記錄：您不僅想要部署活動的歷程記錄，也想要隨時協調生產環境。 您想要了解哪個部署建立了目前的實際執行環境。 有了此知識，即可追蹤設定、測試結果及程式碼本身之類的項目，一直追蹤回到觸發部署的個別提取要求。
部署目標
既然您已知道持續傳遞如何運作，請思考使用 DevOps 做法 (例如，用於部署軟體解決方案) 能夠達成的目標。
目標 1：降低部署服務所造成的壓力，同時提高那些服務的可靠性
這是一種雙贏模式；您不僅能透過減少部署軟體和基礎結構所造成的壓力來提升作業滿意度，也能透過讓系統更可靠來提升作業滿意度與使用者滿意度。 有鑑於這種對客戶體驗的正面影響，技術上來說，這是一種三贏模式。
目標 2：縮短從得知需要變更，到將該變更部署至實際執行環境之間的時間間隔
例如，假設您識別出會對收益造成影響的程式碼瑕疵。 您已確切知道問題所在，也了解如何撰寫修正程式的程式碼。 您得花多少時間，才能將這段程式碼投入生產？ 您需要提取多少字串？ 該如何測試？ 透過 DevOps 做法，您只需撰寫認可程式碼、吃個午餐，並在返回座位前得知問題已解決。
目標 3：降低將想法轉換為可用軟體所花費的時間
此目標與前一個相當類似，但我們談論的是純粹創新，而非實作變更。 採取創新需要多長時間？ 使用此部署模型，即可將新概念整合到實際執行系統，並確信新增的創新不會以任何方式妨礙目前的系統。 確信這一點之後，即可快速傳遞這個新功能。
部署結果
本單元中討論的目標並非僅僅是紙上談兵，而是可實現的。 以下是由 DevOps Research and Assessment（DORA）和 Google Cloud DevOps & SRE 提供的
- 部署數量是 208 倍。
- 從認可到部署的速度提高了 106 倍。
- 變更失敗率降低了 7 倍。
- 事件復原時間加快了 2,604 倍。
這均可提高收益並加快上市時間。
這些數字驗證了部署做法很重要的想法。