停止您正在做的事情，並要求同事定義「雲端原生」一詞。 有一個很好的機會，你會得到幾個不同的答案。
讓我們從簡單的定義開始：
雲端原生架構和技術是設計、建構和作雲端內建工作負載的方法，並充分利用雲端運算模型。
Cloud Native Computing Foundation 提供官方定義：
雲端原生技術可讓組織在現代動態環境中建置及執行可調整的應用程式，例如公用、私人和混合式雲端。 容器、服務網格、微服務、不可變的基礎結構，以及宣告式 API，都示範此方法。
這些技術能夠實現具有彈性、可管理且可觀察特性的鬆耦合系統。 結合強固的自動化功能，其可讓工程師經常且可預測地進行高影響變更，且最少的辛勞。
雲端原生旨在提升速度和靈活度。 商務系統正從啟用商務功能向戰略轉型武器發展，以加速業務速度和成長。 必須立即將新想法推向市場。
同時，商務系統也越來越複雜，使用者要求更多。 他們預期快速回應性、創新功能和零停機時間。 效能問題、週期性錯誤，以及無法快速移動已不再可接受。 您的使用者將會造訪您的競爭對手。 雲端原生系統的設計目的是要採用快速變更、大規模和復原能力。
以下是一些實作雲端原生技術的公司。 想想他們達成的速度、靈活度和延展性。
| 公司 | 體驗 |
|---|---|
| Netflix | 生產環境中有 600 個以上的服務。 每天部署 100 次。 |
| Uber | 生產環境中有 1,000 個以上的服務。 每周部署數千次。 |
| 微信 | 在生產環境中有超過 3,000 個服務項目。 每天部署 1,000 次。 |
如您所見，Netflix、Uber 和 WeChat 會公開由許多獨立服務組成的雲端原生系統。 這種架構風格可讓它們快速響應市場狀況。 它們會立即更新即時複雜應用程式的小型區域，而不需要完整重新部署。 它們會視需要個別調整服務。
雲端原生的支柱
雲端原生的速度和靈活性來源於多種因素。 最重要的是 雲端基礎結構。 但還有更多：圖 1-3 中顯示的其他五個基礎支柱也為雲端原生系統提供基底。
圖 1-3。 雲端原生基礎要素
讓我們花一些時間來進一步瞭解每個支柱的意義。
雲端
雲端原生系統充分利用雲端服務模型。
這些系統專為在動態、虛擬化的雲端環境中茁壯成長，充分利用 平臺即服務 （PaaS） 計算基礎結構和受控服務。 他們將基礎設施視為 可丟棄的 - 透過自動化在幾分鐘內布建，並根據需求進行調整、擴展或移除。
請考慮我們如何對待寵物和商品之間的差異。 在傳統的數據中心，伺服器會被視為寵物：實體機器、指定有意義的名稱，並受到照顧。 您可以藉由將更多資源新增至同一部機器來擴展（垂直擴展）。 如果伺服器生病，您就會將它送回健康狀態。 如果伺服器無法使用，每個人都會注意到。
商品服務模型不同。 您會將每個實例布建為虛擬機或容器。 它們完全相同，並已指派系統標識符，例如 Service-01、Service-02 等等。 您可以藉由建立更多實例來進行橫向擴展。 當實例變成無法使用時，沒有人注意到。
商品模型採用不可變的基礎結構。 伺服器不會修復或修改。 如果其中一個失敗或需要更新，它會被刪除，並透過自動化安排新的。
雲端原生系統採用商品服務模型。 它們會繼續運行，即使基礎設施擴展或縮減，也不受其運行所依賴的機器影響。
Azure 雲端平台支援這種類型的高度彈性基礎結構，具有自動調整、自我修復和監視功能。
新式設計
您要如何設計雲端原生應用程式？ 您的架構看起來會是什麼樣子？ 您應該遵守哪些原則、模式和最佳做法？ 哪些基礎結構和作業考慮很重要？
Twelve-Factor 應用程式
建構雲端式應用程式的廣泛接受方法是 Twelve-Factor 應用程式。 它描述開發人員遵循的一組原則和做法，以建構針對新式雲端環境優化的應用程式。 特別重視跨環境和宣告式自動化的可移植性。
雖然適用於任何 Web 型應用程式，但許多從業者認為 Twelve-Factor 建置雲端原生應用程式的堅實基礎。 以這些原則為基礎的系統可以快速部署和調整規模，並新增功能以快速響應市場變更。
下列表展示了 Twelve-Factor 方法：
| 因數 | 說明 |
|---|---|
| 1 - 程式代碼基底 | 每個微服務的單一程式代碼基底，儲存在自己的存放庫中。 透過版本控制追蹤，它可以部署到多個環境（QA、預備、生產環境）。 |
| 2 - 相依性 | 每個微服務都會隔離並封裝自己的依賴項目，適應變更而不會影響整個系統。 |
| 3 - 組態 | 組態資訊會移出微服務，並透過程式代碼外部的組態管理工具進行外部化。 同樣的部署可以在正確配置到位的環境中擴展。 |
| 4 - 備份服務 | 輔助資源（資料存放區、快取、訊息代理程式）應該透過可尋址 URL 公開。 這樣做會將資源與應用程式分離，使其可交換。 |
| 5 - 組建、發行、執行 | 每個版本都必須在組建、發行和執行階段之間強制執行嚴格的分隔。 每個都應該以唯一識別碼標記，並支持回復的功能。 新式 CI/CD 系統有助於達成此原則。 |
| 6 - 進程 | 每個微服務都應該在自己的進程中執行，與其他執行中的服務隔離。 將所需的狀態外部保存到支持服務，例如分散式快取或資料存儲。 |
| 7 - 埠系結 | 每個微服務都應該獨立自主，其介面和功能會在自己的埠上公開。 這樣做可提供與其他微服務的隔離。 |
| 8 - 並行性 | 當容量需要增加時，應跨多個相同進程水平擴展服務，而不是在最強大的計算機上擴展單一大型實例。 開發應用程式以實現同步操作，使在雲端環境中的擴展變得無縫。 |
| 9 - 可處置性 | 服務實例應該是可處置的。 偏好快速啟動，以增加延展性機會和正常關機，讓系統保持正確狀態。 Docker 容器以及協調器原本就符合這項需求。 |
| 10 - 開發/生產同位 | 盡可能讓整個應用程式生命週期的環境保持類似，避免成本高昂的快捷方式。 在這裡，採用容器可大幅提升相同的執行環境。 |
| 11 - 記錄 | 將微服務所產生的記錄視為事件數據流。 使用事件匯總工具處理它們。 將記錄數據傳播至 Azure 監視器或 Splunk 等數據採礦/記錄管理工具，最後傳播至長期封存。 |
| 12 - 系統管理程式 | 執行管理和行政任務，例如數據清理或計算分析，這些任務可作為單次執行的流程。 使用獨立工具從生產環境叫用這些工作，但與應用程式分開。 |
在書籍《超越Twelve-Factor應用》中，作者凱文·霍夫曼詳細說明了原本的 十二 個因素中的每一個（於2011年撰寫）。 此外，他也會討論三個額外因素，以反映現今的新式雲端應用程式設計。
| 新因素 | 說明 |
|---|---|
| 13 - API 優先 | 讓一切成為服務。 假設前端用戶端、閘道或其他服務會取用您的程式代碼。 |
| 14 - 遙測 | 在工作站上，您可以深入瞭解您的應用程式及其行為。 在雲端中，您不會這麼做。 請確定您的設計包含監視、網域特定和健全狀況/系統數據的集合。 |
| 15 - 驗證/授權 | 從頭開始實作身分識別。 請考慮公用雲端中可用的 RBAC（角色型存取控制） 功能。 |
我們將參考本章和整本書中 12 個以上的許多因素。
Azure Well-Architected 架構
設計和部署雲端式工作負載可能具有挑戰性，尤其是在實作雲端原生架構時。 Microsoft提供業界標準最佳做法，協助您和小組提供強大的雲端解決方案。
Microsoft Well-Architected Framework 提供一組指引原則，可用來改善雲端原生工作負載的品質。 此架構包含五個卓越架構要素：
| 信條 | 說明 |
|---|---|
| 成本管理 | 專注於儘早產生累加值。 套用 Build-Measure-Learn 原則，以加速上市時間，同時避免大量資金的解決方案。 使用隨用隨付策略，隨著擴展而投資，而不是一開始就大量投資。 |
| 卓越營運 | 自動化環境和作業，以提高速度並減少人為錯誤。 快速回復或轉送問題更新。 從一開始就實作監視和診斷。 |
| 效能效率 | 有效地滿足工作負載的要求。 偏好水平擴展，並將其設計到您的系統中。 持續執行效能和負載測試，以找出潛在的瓶頸。 |
| 可靠性 | 建置可復原且可用的工作負載。 復原可讓工作負載從失敗復原並繼續運作。 可用性可確保用戶隨時都能存取您的工作負載。 設計應用程式以預期失敗並從中復原。 |
| 安全性 | 在應用程式的整個生命週期中實作安全性，從設計和實作到部署和作業。 請密切關注身分識別管理、基礎結構存取、應用程式安全性和數據主權和加密。 |
若要開始使用，Microsoft提供一組 在線評量 ，協助您根據五個架構完善的支柱評估目前的雲端工作負載。
微服務
雲端原生系統採用微服務，這是建構現代化應用程式的熱門架構樣式。
微服務建構為一組分散式的小型獨立服務，這些服務透過共用的網路架構互動，並且擁有以下特性：
每個都會在較大的網域內容中實作特定的商務功能。
每個都是自主開發，而且可以獨立部署。
每個都是獨立的，涵蓋其自身的數據存儲技術、相依性和程式開發平台。
每個都會在自己的進程中執行，並使用 HTTP/HTTPS、gRPC、WebSocket 或 AMQP 等標準通訊協定與其他通訊協定進行通訊。
它們會組合在一起以形成應用程式。
圖 1-4 對比整合型應用程式方法與微服務方法。 請注意整合型如何由分層架構組成，該架構會在單一進程中執行。 它通常會取用關係資料庫。 不過，微服務方法會將功能分成獨立的服務，每個服務都有自己的邏輯、狀態和數據。 每個微服務都會裝載自己的數據存放區。
圖 1-4。 整合型與微服務架構
請注意微服務如何促進本章稍早已討論過的 Twelve-Factor 應用程式 的 流程 原則。
Factor #6 指定「每個微服務都應該在自己的進程中執行，並與其他執行中的服務隔離」。
為什麼是微服務？
微服務提供靈活度。
在章節稍早，我們比較了一個建構為單體架構的電子商務應用程式與微服務架構的版本。 在此範例中，我們看到一些明確的優點：
每個微服務都有自主生命週期，而且可以獨立發展並經常部署。 您不需要等候每季發行部署新功能或更新。 您可以更新即時應用程式的小型區域，並降低中斷整個系統的風險。 不需要完整重新部署應用程式，即可進行更新。
每個微服務都可以獨立伸縮。 您不需要將整個應用程式調整為一個整體，而是只擴展那些需要更多處理能力的服務，以達到所需的效能水平和符合服務水平協定。 細粒度的縮放讓您能更精確地控制系統，並協助在不調整整個系統的情況下，降低調整部分系統時的整體成本。
瞭解微服務的絕佳參考指南是 .NET 微服務：容器化 .NET 應用程式的架構。 該書深入探討微服務設計和架構。 它是 完整堆疊微服務參考架構 的隨附專案，可從 Microsoft免費下載。
開發微服務
微服務可以在任何新式開發平臺上建立。
Microsoft .NET 平台是絕佳的選擇。 免費和開放原始碼，其內建功能可簡化微服務開發。 .NET 是跨平臺。 應用程式可以在 Windows、macOS 和大部分的 Linux 上建置並執行。
.NET 非常高效能，與 Node.js 和其他競爭平臺相比，得分良好。 有趣的是， TechEmpower 在許多 Web 應用程式平臺和架構上進行了一組廣泛的 效能基準 檢驗。 .NET 在前 10 名得分， 遠高於 Node.js 和其他競爭平臺。
.NET 是由 GitHub 上的 Microsoft 和 .NET 社群所維護。
微服務挑戰
雖然分散式雲端原生微服務可以提供巨大的靈活度和速度，但它們帶來許多挑戰：
通訊
前端用戶端應用程式如何與後端核心微服務通訊？ 您是否允許直接通訊？ 或者，您是否可以使用提供彈性、控制和安全性的閘道外觀來抽象後端微服務？
後端核心微服務如何彼此通訊？ 您是否允許直接 HTTP 呼叫，以增加結合並影響效能和靈活度？ 或許您考慮使用佇列和主題技術進行解耦的訊息傳遞？
通訊涵蓋在 雲端原生通訊模式一 章中。
韌性
微服務架構會將系統從進程內移至跨進程網路通訊。 在分散式架構中，當服務 B 未回應服務 A 的網路呼叫時，會發生什麼事？ 或者，當服務 C 暫時無法使用，而呼叫它的其他服務會遭到封鎖時，會發生什麼事？
韌性涵蓋在 雲端原生韌性 章中。
分散式數據
根據設計，每個微服務都會封裝自己的數據，並透過其公用介面公開作業。 如果是，您如何查詢數據或跨多個服務實作交易？
分散式數據涵蓋在 雲端原生數據模式章節 中。
密碼
您的微服務如何安全地儲存和管理秘密和機密設定數據？
對於秘密的詳細說明已涵蓋在雲端原生安全性中。
使用 Dapr 管理複雜度
Dapr 是分散式開放原始碼應用程式運行時間。 透過可插即用元件的架構，可大幅簡化分散式應用程式背後的 管道 。 它提供 動態黏合劑，將您的應用程式與 Dapr 執行環境中的預建基礎設施功能和元件相結合。 圖 1-5 顯示高空中的 Dapr。
圖1-5。 達普在 20,000 英尺。
在圖頂端，請注意 Dapr 如何為熱門的開發平臺提供 特定語言 SDK 。 Dapr v1 包含 .NET、Go、Node.js、Python、PHP、Java 和 JavaScript 的支援。
雖然特定語言 SDK 可增強開發人員體驗，但 Dapr 與平台無關。 在幕後，Dapr 的程式設計模型會透過標準 HTTP/gRPC 通訊協議公開功能。 任何程式設計平臺都可以透過其原生 HTTP 和 gRPC API 呼叫 Dapr。
圖中央的藍色方塊代表Dapr的基本構件。 每個都會針對應用程式可取用的分散式應用程式功能公開預先建置的管線程序代碼。
元件數據列代表一組大型預先定義的基礎結構元件，可供您的應用程式取用。 請將元件視為您不需要撰寫的基礎結構程序代碼。
底部數據列會醒目提示 Dapr 的可移植性，以及其可執行的各種環境。
展望未來，Dapr 有可能對雲端原生應用程式開發產生深遠的影響。
容器
在任何雲端原生的討論中提到容器這個詞是很自然的。 在《 雲端原生模式》一書中，作者康妮莉亞·戴維斯觀察到，“容器是雲端原生軟體的絕佳啟用者。Cloud Native Computing Foundation 會將微服務容器化作為 其Cloud-Native 追蹤對應 中的第一個步驟-企業開始雲端原生旅程的指引。
將微服務容器化很簡單且簡單明瞭。 程序代碼、其相依性和運行時間會封裝成稱為 容器映像的二進位檔。 映像會儲存在容器註冊庫中，作為映像的儲存庫。 登錄可以位於您的開發計算機、數據中心或公用雲端。 Docker 本身會透過 Docker Hub 維護公用登錄。 Azure 雲端提供私人 容器登錄 ，以將容器映像儲存在將執行這些映像的雲端應用程式附近。
當應用程式啟動或調整時，您會將容器映像轉換成執行中的容器實例。 實例會在已安裝 容器運行時間 引擎的任何計算機上執行。 您可以依照需求使用多個容器化服務的實例。
圖 1-6 顯示三個不同的微服務，每個微服務都位於自己的容器中，全部都在單一主機上執行。
圖 1-6。 在容器主機上執行的多個容器
請注意，每個容器如何維護自己的一組相依性和執行環境，而這些可能彼此不同。 在這裡，我們看到在相同主機上執行的不同產品微服務版本。 每個容器會共用基礎主機作業系統、記憶體和處理器的一部分，且彼此隔離。
請注意容器模型如何接受來自Twelve-Factor 應用程式的相依性原則。
Factor #2 指出「每個微服務都會隔離並封裝自己的依賴關係，接納變更，而不會影響整個系統」。
容器同時支援Linux和 Windows 工作負載。 Azure 雲端會公開接受這兩者。 有趣的是，Linux，而不是 Windows Server，它已成為 Azure 中較受歡迎的作系統。
雖然有數個容器廠商存在， 但 Docker 已經佔據了市場的主要份額。 該公司一直在推動軟體容器移動。 它已成為封裝、部署和執行雲端原生應用程式的事實上標準。
為什麼是容器？
容器提供跨環境的可移植性及保證一致性。 將所有專案封裝成單一套件，即可 將 微服務及其相依性與基礎結構隔離。
您可以在裝載 Docker 執行時間引擎的任何環境中部署容器。 容器化工作負載還能消除以架構、軟體連結庫和執行引擎提前配置每個環境所需的費用。
藉由共用基礎作系統和主機資源，容器的使用量會比完整虛擬機小得多。 較小的大小會增加給定主機可以一次執行的 密度或微服務數目。
容器編排
雖然 Docker 之類的工具會建立映像並執行容器，但您也需要工具來管理它們。 容器管理是使用稱為 容器協調器的特殊軟體程式來完成。 使用許多獨立執行容器大規模運作時，協調流程至關重要。
圖 1-7 顯示容器協調器自動化的管理工作。
圖 1-7。 容器協調器執行的動作
下表描述常見的編排工作。
| 任務 | 說明 |
|---|---|
| 排程 | 自動布建容器實例。 |
| 親和/反親和 | 在附近或彼此相距甚遠的地方布建容器，以協助可用性和效能。 |
| 健康狀態監視 | 自動偵測並更正故障。 |
| 故障轉移 | 自動將失敗的實例重新布建至狀況良好的計算機。 |
| 縮放 | 自動新增或移除容器實例以符合需求。 |
| 網路 | 管理容器通訊的網路覆蓋。 |
| 服務探索 | 啟用容器之間的定位功能。 |
| 滾動升級 | 協調進行逐步升級，實現零停機時間部署。 自動回復有問題的變更。 |
請注意容器協調器如何採用來自Twelve-Factor 應用程式的可處置性和並行性原則。
Factor #9 指定「服務實例應該是可處置的，有利於快速啟動，以增加延展性機會和正常關機，讓系統保持正確狀態」。 Docker 容器以及協調器原本就滿足此需求。
Factor #8 說明「服務會將大量小型且相同的程式（副本）進行水平擴展，而不是在最強大的計算機上垂直擴展單個大型實例。
雖然有數個容器協調器存在， 但 Kubernetes 已成為雲端原生世界事實上的標準。 它是可攜式、可延伸的開放原始碼平臺，可用來管理容器化工作負載。
您可以裝載自己的 Kubernetes 實例，但接著您必須負責布建和管理其資源，這可能會相當複雜。 Azure 雲端會將 Kubernetes 作為受控服務。 Azure Kubernetes Service （AKS） 和 Azure Red Hat OpenShift （ARO） 都可讓您完全運用 Kubernetes 作為受控服務的功能和功能，而不需要安裝和維護它。
容器編排在調整 Cloud-Native 應用程式中有詳盡的說明。
備份服務
雲端原生系統相依於許多不同的輔助資源，例如數據存放區、訊息代理程式、監視和身分識別服務。 這些服務稱為 備份服務。
圖 1-8 顯示雲端原生系統取用的許多常見備份服務。
圖 1-8。 一般備份服務
您可以裝載自己的支援服務，但接著您必須負責授權、布建和管理這些資源。
雲端提供者提供豐富的 受控支援服務。 您不需要擁有服務，而是直接取用它。 雲端服務提供者會大規模管理資源，並負責效能、安全性和維護。 監視、備援和可用性內建在服務中。 提供者保證服務水準表現並完全支援其受控服務 - 提交支援請求後，他們會修正您的問題。
雲端原生系統支援來自雲端廠商的受控支持服務。 時間和人力的節省可能相當重要。 自行管理操作風險並遇到問題可能會很快變得昂貴。
最佳做法是將備份服務視為 附加資源，以動態方式系結至儲存在外部組態中的組態資訊（URL 和認證）的微服務。 本指引會詳寫在 Twelve-Factor 應用程式中，本章稍早討論。
Factor #4 指定支援服務「應該透過可尋址 URL 公開。 這樣做會將資源與應用程式分離，使其可互換。
Factor #3 指定「組態資訊已移出微服務，並透過程式代碼外部的組態管理工具進行外部化」。
使用此模式時，可以附加和中斷鏈接支援服務，而不需變更程序代碼。 您可以將微服務從 QA 升級至預備環境。 您可以更新微服務組態，以指向預備中的備份服務，並透過環境變數將設定插入容器中。
雲端廠商提供 API，讓您與其專屬支援服務通訊。 這些函式庫封裝專有的内部機制和複雜性。 不過，直接與這些 API 通訊會將您的程式代碼緊密結合至該特定備份服務。 這是廣泛接受的做法，可隔離廠商 API 的實作詳細數據。 引入中間層或中繼 API，與服務程式碼交互，公開通用操作，並將廠商程式碼封裝在其中。 這種鬆散結合可讓您交換出一個備份服務，或將程式代碼移至不同的雲端環境，而不需要變更主線服務程序代碼。 先前討論的 Dapr 會遵循此模型及其 一組預先建置的建置組塊。
在考慮到這一點後，支援服務也進一步促進了章節稍早提到的 Twelve-Factor 應用程式的無狀態性原則。
Factor #6 指定「每個微服務都應該在自己的進程中執行，並與其他執行中的服務隔離。 將所需狀態外部化到後端服務，例如分散式快取或數據存放區。
支援服務會在 雲端原生數據模式 和 雲端原生通訊模式中討論。
Automation
如您所見，雲端原生系統採用微服務、容器和現代化系統設計，以達到速度和靈活性。 但是，這隻是故事的一部分。 如何布建這些系統執行所在的雲端環境？ 如何快速部署應用程式功能和更新？ 如何全面了解整體情況？
輸入廣泛接受的 基礎結構即程序代碼或 IaC 做法。
透過 IaC，您將平臺佈建和應用程式部署自動化。 您基本上會將測試與版本控制等軟體工程實務套用至 DevOps 實務。 您的基礎結構和部署是自動化、一致且可重複的。
自動化基礎結構
Azure Resource Manager、來自 HashiCorp 的 Azure Bicep、Terraform 和 Azure CLI 等工具可讓您以宣告方式編寫所需的雲端基礎結構腳本。 資源名稱、位置、容量和秘密會參數化和動態。 腳本已版本化，並提交至版本控制系統，作為專案的工件。 您可以叫用腳本，以跨系統環境布建一致且可重複的基礎結構，例如 QA、預備和生產環境。
在幕後，IaC 具有等冪性，這表示您可以一遍又一遍地執行相同的腳本，而不會產生副作用。 如果小組需要進行變更，他們會編輯並重新執行腳本。 只會影響更新的資源。
在文章中， 什麼是基礎結構即程序代碼，作者 Sam Guckenheimer 說明「實作 IaC 的 Teams 如何快速且大規模地提供穩定環境。 它們可避免手動設定環境，並透過程式代碼代表其環境所需的狀態，以強制執行一致性。 使用 IaC 的基礎結構部署是可重複的，並防止因設定漂移或遺失相依性所造成的運行時間問題。 DevOps 小組可以與一組統一的做法和工具合作，以快速、可靠且大規模地傳遞應用程式和其支援的基礎結構。
自動化部署
稍早討論的 Twelve-Factor 應用程式，在將已完成的程式碼轉換成可執行的應用程式時，需要進行各個步驟。
Factor #5 指定「每個版本都必須在組建、發行和執行階段之間強制執行嚴格的分隔。 每個應該標記以唯一ID，並支持復原功能。
新式 CI/CD 系統有助於達成此原則。 它們提供個別的建置和傳遞步驟，可協助確保用戶隨時可用的一致和品質程序代碼。
圖 1-9 顯示部署流程的分隔。
圖 1-9。 CI/CD 管線中的部署步驟
在上圖中，請特別注意工作分離：
- 開發人員在其開發環境中建構功能，逐一查看程式代碼、執行和偵錯的「內部迴圈」。
- 完成時，該程式代碼 會推送 至程式代碼存放庫，例如 GitHub、Azure DevOps 或 BitBucket。
- 推送會觸發將程式代碼轉換成二進位成品的建置階段。 工作是使用 持續整合 （CI） 管線來實作。 它會自動建置、測試和封裝應用程式。
- 發行階段會挑選二進位制產物、應用外部應用程式和環境配置資訊，產生不可變的版本。 發行會部署到指定的環境。 工作是使用 持續交付 （CD） 管線來實作。 每個版本都應該可識別。 您可以說：「此部署正在執行應用程式的 2.1.1 版」。
- 最後，發行的功能會在目標執行環境中執行。 版本是不可變的，這表示任何變更都必須建立新版本。
套用這些做法時，組織已徹底演進了其寄送軟體的方式。 許多人已從每季發行移至隨選更新。 目標是在開發週期早期攔截問題，因為它們的修正成本較低。 整合之間的間隔時間越長，解決問題的成本就越高。 在整合過程中保持一致性，團隊可以更頻繁地提交程式碼變更，進而提升協作效率和軟體品質。
DevOps 中會詳細討論基礎設施即程式碼、自動化部署，以及 GitHub 和 Azure DevOps。
