使用持續傳遞以較低成本和風險來加快發行速度
持續傳遞是 DevOps 分類法八大功能的其中一個。
探索需要持續傳遞的原因
在 2012 年時，軟體部署錯誤導致當時美國股市中最大交易商 Knight Capital Group 損失了 4 億 6000 萬美元。
損失從一開市便開始了。 程式碼中沒有任何錯誤 (bug) – 之所以發生此問題，是因為他們在對八個生產伺服器中的其中一個執行手動部署時發生錯誤。
當他們嘗試修正此問題時，卻導致最終所有八個伺服器的設定都不正確，因此損失更多金錢。 由於所有部署都是手動進行，因此沒有任何方法可將變更自動復原。
在嘗試修正 45 分鐘之後，他們最後關閉了整個系統。 在這段時間內，他們損失了 4 億 6000 萬美元。
這是真實故事。 這在您組織會造成什麼影響？ 您是否正以手動方式進行部署？
或許，協助您了解組織中傳遞效能的最重要問題是：
重要
您生產環境的部署壓力有多大？
當工程師和技術人員將程式碼推送到生產環境時，他們所感覺到的恐懼與焦慮可以透露有關小組軟體傳遞效能的許多資訊。
什麼是持續傳遞？
重要
持續傳遞是一種軟體工程方法，可讓小組以較短的週期來產生軟體，以確保軟體能夠：
- 隨時可靠地發行
- 手動發行
持續傳遞的目的是：
- 以更快的速度和頻率建立、測試和發行軟體
- 在生產環境中允許更多應用程式的增量更新，以降低傳遞變更的成本、時間和風險
持續傳遞的發生時機：
- 軟體可在整個生命週期中部署
- 持續整合和廣泛的自動化都可在傳遞程序 (通常是使用部署管線) 的所有可能部分中使用
- 您可以根據需求，對任何環境執行任何版本軟體的一鍵部署
大型手動部署會大幅增加所發行軟體的複雜性、提高人為錯誤的可能性，以及更難以識別風險和補救部署失敗，進而提高風險層級。 部署頻率低，變更的前置時間長、平均復原時間長，而且有較高的變更失敗率。
指定的作業小組會在非上班時間執行手動部署。 他們需要手動步驟的文件，還需要時間來手動測試記載的步驟。 大型部署也需要較長的執行時間，失敗時較難復原，而且在部署之後需要更大的測試範圍。 每個部署的變更數目都偏大，而且意見反應需要更多時間來實作。
因具有將程序自動化及隨時都能發行至生產環境的功能，持續傳遞的優點不僅顯著而且很多：
- 減少浪費
- 更快速的 ROI
- 降低風險
- 提高品質
- 早期意見反應
- 更好的規劃
- 更快速的共同作業
- 每個人皆參與其中
- 較少的生產環境問題
- 安全性上的左移能力
- 更快速地調整和回應
- 更容易預測的發行
- 在任何上班時間進行部署
- 更快速地回應市場變更
- 在沒有顯著延遲的情況下傳遞變更
- 小組中的任何人都可以起始部署
- 快速、可重複且可設定的部署
根據 2019 的 DevOps 狀態報告，相較於績效較低者，高績效的 DevOps 組織可達到下列成就：
- 部署頻率高於 200 倍
- 變更前置時間加快超過 100 倍
- 復原平均時間加快超過 2600 倍
- 變更失敗率降低了七倍之多
此外，根據 CA Technologies 的全球研究，在上市時間和收益增加方面，組織可實現高達 20% 的改善。
注意
持續傳遞有時會與持續部署混淆。 持續部署表示每項變更都會通過管線，並自動進入生產環境，進而每天產生許多生產部署。 持續傳遞只是表示您可以進行頻繁的部署，但也可以選擇不這麼做，通常這是因為企業偏好較慢的部署速度。 您必須進行持續傳遞，才能進行持續部署。
持續整合是持續傳遞的先決條件。 現行做法可讓您以較高的品質，隨時從原始檔控制中建置及 (可靠地) 部署應用程式。
