什麼是雲端原生?

提示

此內容是電子書的摘錄:架構適用于 Azure 的雲端原生 .NET 應用程式,可在 .NET Docs 上取得,或以可離線閱讀的免費可下載 PDF 形式提供。

Cloud Native .NET apps for Azure eBook cover thumbnail.

停止您執行的動作,並要求同事定義「雲端原生」一詞。 您有機會得到數個不同的答案。

讓我們從簡單的定義開始:

雲端原生架構和技術是設計、建構和操作工作負載的方法,這些工作負載是在雲端中建置,並充分利用雲端運算模型。

Cloud Native Computing Foundation提供官方定義

雲端原生技術可讓組織在現代化、動態環境中建置和執行可調整的應用程式,例如公用、私人和混合式雲端。 容器、服務網格、微服務、不可變的基礎結構,以及宣告式 API 會示範此方法。

這些技術可啟用彈性、可管理且可觀察的鬆散結合系統。 與健全的自動化結合,可讓工程師頻繁且可預測的變更,且最少的垃圾。

雲端原生是關於速度和靈活度。 商務系統不斷演進,從啟用商務功能到策略性轉型,以加速業務速度和成長。 請務必立即取得上市的新想法。

同時,商務系統也會隨著使用者要求更多而變得更複雜。 他們預期快速回應性、創新功能,以及零停機時間。 無法再接受效能問題、週期性錯誤,以及無法快速移動。 您的使用者將會造訪您的競爭對手。 雲端原生系統的設計目的是要採用快速變更、大規模和復原能力

以下是已實作雲端原生技術的一些公司。 思考其達成的速度、靈活度和延展性。

公司 體驗
Netflix 生產環境中有 600 個以上的服務。 每天部署 100 次。
Uber 生產環境中有 1,000 個以上的服務。 每週部署數千次。
微信 生產環境中有 3,000 個以上的服務。 每天部署 1,000 次。

如您所見,Uber、Uber 和 WeChat 會公開由許多獨立服務組成的雲端原生系統。 此架構樣式可讓他們快速回應市場狀況。 它們會立即更新即時、複雜應用程式的小型區域,而不需要完整重新部署。 它們會視需要個別調整服務。

雲端原生的要素

雲端原生的速度和靈活度衍生自許多因素。 最重要的是 雲端基礎結構。 但還有更多:圖 1-3 中顯示的五個其他基礎要素也會為雲端原生系統提供基底。

Cloud-native foundational pillars

圖 1-3。 雲端原生基礎要素

讓我們花一些時間進一步瞭解每個要素的重要性。

雲端

雲端原生系統充分利用雲端服務模型。

這些系統專為在動態、虛擬化的雲端環境中成長而設計,可廣泛運用 平臺即服務 (PaaS) 計算基礎結構和受控服務。 他們會透過自動化,將基礎結構視為 可處置 的-在幾分鐘內布建,並依需求調整、調整或終結。

請考慮寵物與寵物與寵物的廣泛接受DevOps概念。 在傳統的資料中心,伺服器會被視為 寵物:實體機器、指定有意義的名稱,並 負責處理 。 您可以將更多資源新增至相同的電腦, (相應增加) 。 如果伺服器發生疾病,您會將它帶回健康狀態。 如果伺服器無法使用,每個人都會注意到。

「建議」服務模型不同。 您會將每個實例布建為虛擬機器或容器。 它們完全相同,並指派了系統識別碼,例如 Service-01、Service-02 等等。 您可以藉由建立更多專案, (相應放大) 。 當一個變成無法使用時,沒有人會注意到。

此模型採用 不可變的基礎結構。 伺服器不會修復或修改。 如果一個失敗或需要更新,則會終結,並布建新的更新,全部都是透過自動化完成。

雲端原生系統採用「Azure 服務」模型。 它們會繼續在基礎結構相應縮小或相應放大時執行,而不論其執行所在的機器為何。

Azure 雲端平臺支援這種高度彈性的基礎結構,其中包含自動調整、自我修復和監視功能。

新式設計

您要如何設計雲端原生應用程式? 您的架構看起來會像什麼? 您應該遵守哪些原則、模式和最佳做法? 哪些基礎結構和作業考慮很重要?

Twelve-Factor應用程式

建構雲端式應用程式的廣泛接受方法是 十二因素應用程式。 其描述開發人員遵循的一組原則和做法,以建構針對新式雲端環境優化的應用程式。 特別注意跨環境和宣告式自動化的可攜性。

雖然適用于任何 Web 應用程式,但許多執行者都認為Twelve-Factor建置雲端原生應用程式的穩固基礎。 以這些原則為基礎的系統可以快速部署和調整規模,並新增功能以快速回應市場變更。

下表強調Twelve-Factor方法:

因素 說明
1 - 程式碼基底 每個微服務的單一程式碼基底,儲存在自己的存放庫中。 透過版本控制追蹤,它可以部署至多個環境, (QA、預備、生產) 。
2 - 相依性 每個微服務都會隔離並封裝自己的相依性,並採用變更,而不會影響整個系統。
3 - 組態 組態資訊會移出微服務,並透過程式碼外部的組態管理工具進行外部化。 相同的部署可以在套用正確組態的環境中傳播。
4 - 備份服務 (資料存放區、快取、訊息代理程式) 的輔助資源應透過可定址 URL 公開。 這麼做會將資源與應用程式分離,使其可交換。
5 - 組建、發行、執行 每個版本都必須在組建、發行和執行階段之間強制執行嚴格的分隔。 每個都應該以唯一識別碼標記,並支援復原的能力。 新式 CI/CD 系統有助於滿足此原則。
6 - 進程 每個微服務都應該在自己的進程中執行,並與其他執行中的服務隔離。 將備份服務所需的狀態外部化,例如分散式快取或資料存放區。
7 - 埠系結 每個微服務都應該與其在自己的埠上公開的介面和功能獨立。 這麼做可提供與其他微服務的隔離。
8 - 並行 當容量需要增加時,跨多個相同進程水準相應放大服務, (複製) ,而不是在最強大的電腦上相應增加單一大型實例。 開發應用程式,使其在雲端環境中順暢地相應放大。
9 - 可處置性 服務實例應該是可處置的。 偏好快速啟動以增加延展性機會和正常關機,讓系統保持正確狀態。 Docker 容器以及協調器原本就符合此需求。
10 - 開發/Prod 同位 盡可能讓整個應用程式生命週期的環境保持類似,以避免成本高昂的快捷方式。 在這裡,採用容器可藉由提升相同的執行環境來大幅貢獻。
11 - 記錄 將微服務所產生的記錄視為事件資料流程。 使用事件匯總工具來處理它們。 將記錄資料傳播至資料採礦/記錄管理工具,例如 Azure 監視器或 Splunk,最後會傳播到長期封存。
12 - 系統管理程式 以一次性程式執行系統管理/管理工作,例如資料清理或計算分析。 使用獨立工具來從生產環境叫用這些工作,但與應用程式分開。

在除了 Twelve-Factor應用程式之外,作者 Kevin Hoffman 會詳細說明 2011) 撰寫的原始 12 因素 (。 此外,他會討論反映現今新式雲端應用程式設計的三個額外因素。

New Factor 說明
13 - API 優先 讓所有專案成為服務。 假設前端用戶端、閘道或其他服務會取用您的程式碼。
14 - 遙測 在工作站上,您可以深入瞭解您的應用程式及其行為。 在雲端中,您不會這麼做。 請確定您的設計包含監視、網域特定和健康情況/系統資料的集合。
15 - 驗證/授權 從頭開始實作身分識別。 請考慮 RBAC (公用雲端中可用的角色型存取控制) 功能。

我們將在本章和整個書籍中參考許多 12 個以上因素。

Azure 架構完善的架構

設計和部署雲端式工作負載可能很困難,特別是在實作雲端原生架構時。 Microsoft 提供業界標準最佳做法,可協助您和小組提供強大的雲端解決方案。

Microsoft Well-Architected Framework提供一組指引原則,可用來改善雲端原生工作負載的品質。 該架構包含五個卓越的架構要素:

信條 描述
成本管理 專注于提早產生累加值。 套用 Build-Measure-Learn 原則,以加速上市時間,同時避免大量資本的解決方案。 使用隨用隨付策略,在相應放大時投資,而不是預付大量投資。
卓越營運 將環境和作業自動化,以加快速度並減少人為錯誤。 快速回復或向前復原問題更新。 從頭開始實作監視和診斷。
效能效率 有效率地符合工作負載上的需求。 偏好水準縮放 (相應放大) ,並將其設計到您的系統中。 持續執行效能和負載測試,以找出潛在的瓶頸。
可靠性 建置可復原且可用的工作負載。 復原功能可讓工作負載從失敗中復原並繼續運作。 可用性可確保使用者隨時都能存取您的工作負載。 設計應用程式以預期失敗並從中復原。
安全性 在應用程式的整個生命週期中實作安全性,從設計和實作到部署和作業。 請密切注意身分識別管理、基礎結構存取、應用程式安全性和資料主權和加密。

為了開始,Microsoft 提供一組 線上評定 ,可協助您根據五個架構完善的要素評估目前的雲端工作負載。

微服務

雲端原生系統採用微服務,這是建構現代化應用程式的熱門架構樣式。

建置為透過共用網狀架構互動的一組小型獨立服務,微服務會共用下列特性:

  • 每個都會在較大的網域內容中實作特定的商務功能。

  • 每個都是由自發開發,而且可以獨立部署。

  • 每個都是獨立封裝自己的資料儲存技術、相依性和程式設計平臺。

  • 每個都會在自己的進程中執行,並使用 HTTP/HTTPS、gRPC、WebSocket 或 AMQP等標準通訊協定來與其他人通訊。

  • 它們會組合在一起以形成應用程式。

圖 1-4 對比整合型應用程式方法與微服務方法。 請注意整合型如何由在單一進程中執行的分層架構所組成。 它通常會取用關係資料庫。 不過,微服務方法會將功能分成獨立的服務,每個服務都有自己的邏輯、狀態和資料。 每個微服務都會裝載自己的資料存放區。

Monolithic deployment versus microservices

圖 1-4。 整合型與微服務架構

請注意微服務如何從12-Factor Application升階程式原則,本章稍早討論。

Factor #6 指定「每個微服務都應該在自己的進程中執行,並與其他執行中的服務隔離。」

使用微服務的理由?

微服務提供靈活度。

稍早在本章中,我們會比較以整合型方式建置的電子商務應用程式與微服務。 在此範例中,我們看到一些清楚的優點:

  • 每個微服務都有自發生命週期,可以獨立發展並經常部署。 您不需要等候每季發行來部署新功能或更新。 您可以更新即時應用程式的小型區域,並降低中斷整個系統的風險。 不需要完整重新部署應用程式,即可進行更新。

  • 每個微服務都可以獨立調整。 您不需要將整個應用程式調整為單一單位,而是只相應放大需要更多處理能力的服務,以符合所需的效能等級和服務等級協定。 更精細的調整可讓您更充分地控制您的系統,並協助您在調整系統部分時降低整體成本,而不是所有專案。

瞭解微服務的絕佳參考指南是 .NET 微服務:容器化 .NET 應用程式的架構。 本書籍深入探討微服務設計和架構。 這是 完整堆疊微服務參考架構 的隨附套件,可從 Microsoft 免費下載。

開發微服務

微服務可以在任何新式開發平臺上建立。

Microsoft .NET 平臺是絕佳的選擇。 免費和開放原始碼,它有許多可簡化微服務開發的內建功能。 .NET 是跨平臺。 應用程式可以在 Windows、macOS 和大部分的 Linux 類型上建置和執行。

.NET 效能很高,相較于Node.js和其他競爭平臺,其評分良好。 有趣的是, TechEmpower 在許多 Web 應用程式平臺和架構上進行了一組廣泛的 效能基準 檢驗。 在前 10 名中評分的 .NET - 高於Node.js和其他競爭平臺。

.NET是由 Microsoft 和 .NET 社群在 GitHub 維護。

微服務挑戰

雖然分散式雲端原生微服務可以提供極大的靈活度和速度,但它們帶來許多挑戰:

通訊

前端用戶端應用程式如何與後端核心微服務通訊? 您是否允許直接通訊? 或者,您是否可以使用提供彈性、控制和安全性的閘道外觀來抽象後端微服務?

後端核心微服務如何彼此通訊? 您是否允許可增加結合和影響效能和靈活性的直接 HTTP 呼叫? 或者,您是否考慮使用佇列和主題技術分離傳訊?

通訊涵蓋在 雲端原生通訊模式 一章中。

復原

微服務架構會將您的系統從進程內移至跨進程網路通訊。 在分散式架構中,當服務 B 未回應來自服務 A 的網路呼叫時,會發生什麼情況? 或者,當服務 C 暫時無法使用,而呼叫它的其他服務會遭到封鎖時,會發生什麼事?

復原功能涵蓋在 雲端原生復原 一章中。

分散式資料

根據設計,每個微服務都會封裝自己的資料,並透過其公用介面公開作業。 如果是,您要如何查詢資料或跨多個服務實作交易?

分散式資料涵蓋在 雲端原生資料模式 一章中。

密碼

您的微服務如何安全地儲存和管理秘密和敏感性設定資料?

秘密會詳細涵蓋 雲端原生安全性

使用 Dapr 管理複雜度

Dapr 是分散式開放原始碼應用程式執行時間。 透過可插即用元件的架構,可大幅簡化分散式應用程式背後的 管架 。 它提供 動態黏附 ,可系結應用程式與 Dapr 執行時間中預先建置的基礎結構功能和元件。 圖 1-5 顯示 20,000 英呎的 Dapr。

Dapr at 20,000 feet圖 1-5。 Dapr 為 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 的可攜性,以及其可執行檔各種環境。

Microsoft 提供 適用于 .NET 開發人員的免費電子書 Dapr 來學習 Dapr

向前看,Dapr 可能會對雲端原生應用程式開發造成重大影響。

容器

聆聽任何雲端原生交談中所提及的容器一詞是自然的。 在 Cloud Native Patterns書籍中,Author Cornelia 的作者發現「容器是雲端原生軟體的絕佳啟用者」。Cloud Native Computing Foundation 會將微服務容器化放在其 Cloud-Native Trail Map 中的第一個步驟-企業開始其雲端原生旅程的指引。

將微服務容器化是簡單且直接的。 程式碼、其相依性和執行時間會封裝成稱為 容器映射的二進位檔。 映射會儲存在容器登錄中,作為映射的存放庫或程式庫。 登錄可以位於您的開發電腦、資料中心或公用雲端。 Docker 本身會透過Docker Hub維護公用登錄。 Azure 雲端具有私人 容器登錄 ,可儲存接近將執行容器應用程式的容器映射。

當應用程式啟動或調整時,您會將容器映射轉換成執行中的容器實例。 實例會在已安裝 容器執行時間 引擎的任何電腦上執行。 您可以視需要擁有容器化服務的實例數目。

圖 1-6 顯示三個不同的微服務,每個微服務分別在自己的容器中,全都在單一主機上執行。

Multiple containers running on a container host

圖 1-6. 在容器主機上執行的多個容器

請注意,每個容器如何維護自己的相依性和執行時間集合,這可以彼此不同。 在這裡,我們看到在相同主機上執行的不同產品微服務版本。 每個容器共用基礎主機作業系統、記憶體和處理器的配量,但彼此隔離。

請注意容器模型從十二因素應用程式採用相依性準則有多好。

Factor #2 指定「每個微服務都會隔離並封裝自己的相依性,並採用變更而不會影響整個系統」。

容器同時支援 Linux 和Windows工作負載。 Azure 雲端開放採用這兩者。 有趣的是,它不是Windows Server,它已成為 Azure 中較熱門的作業系統。

雖然有數個容器廠商存在, 但 Docker 已擷取市場的主要佔有率。 該公司已推動軟體容器移動。 它已成為封裝、部署和執行雲端原生應用程式的事實標準。

為什麼要使用容器?

容器可在環境中提供可攜性和保證一致性。 藉由將一切封裝成單一套件,您可以將微服務及其相依性與基礎結構 隔離

您可以在裝載 Docker 執行時間引擎的任何環境中部署容器。 容器化工作負載也不需要使用架構、軟體程式庫和執行時間引擎預先設定每個環境的費用。

藉由共用基礎作業系統和主機資源,容器的使用量會比完整虛擬機器小很多。 較小的大小會增加指定主機一次可執行檔 密度或微服務數目。

容器協調流程

雖然 Docker 之類的工具會建立映射並執行容器,但您也需要工具來管理它們。 容器管理是使用稱為 容器協調器的特殊軟體程式來完成。 使用許多獨立執行的容器大規模運作時,協調流程是不可或缺的。

圖 1-7 顯示容器協調器自動化的管理工作。

What container orchestrators do

圖 1-7。 容器協調器的功能

下表描述常見的協調流程工作。

工作 說明
排程 自動布建容器實例。
Affinity/anti-affinity 將容器布建在附近或彼此相隔的地方,以協助可用性和效能。
健康狀況監視 自動偵測並更正失敗。
容錯移轉 自動將失敗的實例重新布建到狀況良好的電腦。
調整大小 自動新增或移除容器實例以符合需求。
網路 管理容器通訊的網路重迭。
服務探索 讓容器彼此尋找。
輪流升級 協調累加升級,並無停機時間部署。 自動回復有問題的變更。

請注意容器協調器如何採用12-Factor Application可處置性和並行原則

Factor #9 指定「服務實例應可處置,偏好快速啟動以增加延展性機會和正常關機,讓系統保持正確狀態」。 Docker 容器以及協調器原本就符合此需求。」

Factor #8 指定「服務會跨大量小型相同的進程相應放大, (複本) ,而不是在最強大的電腦上相應增加單一大型實例」。

雖然有數個容器協調器存在, 但 Kubernetes 已成為雲端原生世界的事實標準。 它是可攜式、可延伸的開放原始碼平臺,用於管理容器化工作負載。

您可以裝載自己的 Kubernetes 實例,但接著您必須負責布建和管理其資源,這可能會相當複雜。 Azure 雲端會將 Kubernetes 作為受控服務。 Azure Kubernetes Service (AKS) Azure Red Hat OpenShift (ARO) 可讓您完全運用 Kubernetes 的功能和功能作為受控服務,而不需要安裝和維護它。

調整Cloud-Native應用程式中,會詳細說明容器協調流程。

備份服務

雲端原生系統相依于許多不同的輔助資源,例如資料存放區、訊息代理程式、監視和身分識別服務。 這些服務稱為 備份服務

圖 1-8 顯示雲端原生系統取用的許多常見備份服務。

Common backing services

圖 1-8. 常見的備份服務

您可以裝載自己的支援服務,但接著您必須負責授權、布建和管理這些資源。

雲端提供者提供豐富的 受控支援服務。 您不需要擁有服務,而是直接取用服務。 雲端提供者會大規模操作資源,並負責效能、安全性和維護。 監視、備援和可用性會內建于服務中。 提供者保證服務等級效能並完全支援其受控服務 - 開啟票證並修正您的問題。

雲端原生系統偏好來自雲端廠商的受控支援服務。 時間與人力的節省可能相當重要。 裝載您自己的作業風險,且遇到問題可能很快。

最佳做法是將備份服務視為 附加資源,並以設定資訊動態系結至微服務, (URL 和認證) 儲存在外部組態中。 本指引在 12-Factor Application中拼字說明,本章稍早討論。

Factor #4 指定支援服務「應該透過可定址 URL 公開。 這麼做會將資源與應用程式分離,使其可交換。」

Factor #3 指定「組態資訊已移出微服務,並透過程式碼外部的組態管理工具進行外部化」。

使用此模式時,可以附加和卸離支援服務,而不需變更程式碼。 您可以將微服務從 QA 升階至預備環境。 您可以更新微服務組態,以指向預備中的備份服務,並透過環境變數將設定插入容器中。

雲端廠商提供 API 供您與其專屬支援服務通訊。 這些程式庫會封裝專屬的管子和複雜度。 不過,直接與這些 API 通訊會將您的程式碼緊密結合到該特定備份服務。 這是廣泛接受的做法,可隔離廠商 API 的實作詳細資料。 引進仲介層或中繼 API,將泛型作業公開至您的服務程式代碼,並在其中包裝廠商程式碼。 這種鬆散結合可讓您交換一個支援服務,或將程式碼移至不同的雲端環境,而不需要變更主線服務程式代碼。 稍早討論的 Dapr 會遵循此模型及其 一組預先建置的建置組塊

最後一點,支援服務也會從十二因素應用程式提升無狀態原則,本章稍早討論。

Factor #6 指定:「每個微服務都應該在自己的進程中執行,與其他執行中的服務隔離。 將支援服務所需的狀態外部化,例如分散式快取或資料存放區。」

支援服務會在 雲端原生資料模式雲端原生通訊模式中討論。

自動化

如您所見,雲端原生系統採用微服務、容器和現代化系統設計,以達到速度和靈活度。 但這只是本文的一部分。 如何布建這些系統執行所在的雲端環境? 如何快速部署應用程式功能和更新? 如何四捨五入全貌?

輸入 廣泛接受的基礎結構即程式碼或 IaC 做法。

透過 IaC,您可以自動化平臺布建和應用程式部署。 您基本上會將軟體工程實務,例如測試和版本設定套用至您的DevOps做法。 您的基礎結構和部署是自動化、一致且可重複的。

自動化基礎結構

Azure Resource ManagerAzure Bicep、HashiCorp 的TerraformAzure CLI等工具可讓您以宣告方式編寫所需的雲端基礎結構腳本。 資源名稱、位置、容量和秘密會參數化且動態。 腳本會建立版本,並簽入原始檔控制作為專案的成品。 您可以叫用腳本,跨系統內容布建一致且可重複的基礎結構,例如 QA、預備和生產環境。

在幕後,IaC 是等冪的,這表示您可以重複執行相同的腳本,而不會產生副作用。 如果小組需要進行變更,他們會編輯並重新執行腳本。 只會影響更新的資源。

什麼是基礎結構即程式碼的文章中,作者 Sam Gucken Teams說明「Teams實作 IaC 的人員可以快速且大規模地提供穩定環境。 它們可避免手動設定環境,並透過程式碼代表其環境的預期狀態來強制執行一致性。 具有 IaC 的基礎結構部署是可重複的,並防止設定漂移或遺失相依性所造成的執行時間問題。 DevOps小組可以與一組統一的做法和工具合作,以快速、可靠且大規模地提供應用程式和其支援基礎結構。」

自動化部署

稍早討論的 十二因素應用程式會在將完成的程式碼轉換成執行中的應用程式時,呼叫個別步驟。

Factor #5 指定「每個版本都必須在建置、發行和執行階段之間強制執行嚴格分隔。 每個都應該以唯一識別碼標記,並支援復原的能力。」

新式 CI/CD 系統有助於滿足此原則。 它們提供個別的建置和傳遞步驟,以協助確保使用者隨時可用的一致和品質程式碼。

圖 1-9 顯示跨部署程式的區隔。

Deployments Steps in CI/CD Pipeline

圖 1-9。 CI/CD 管線中的部署步驟

在上圖中,請特別注意工作分離:

  1. 開發人員在其開發環境中建構功能,逐一查看程式碼、執行和偵錯的「內部迴圈」。
  2. 完成時,該程式碼會推送至程式碼存放庫,例如GitHub、Azure DevOps或 BitBucket。
  3. 推送會觸發建置階段,將程式碼轉換成二進位成品。 工作是使用 持續整合 (CI) 管線來實作。 它會自動建置、測試和封裝應用程式。
  4. 發行階段會挑選二進位成品、套用外部應用程式和環境組態資訊,並產生不可變的版本。 發行會部署至指定的環境。 工作是使用 持續傳遞 (CD) 管線來實作。 每個版本都應該可識別。 您可以說:「此部署正在執行應用程式的 2.1.1 版」。
  5. 最後,已發行的功能會在目標執行環境中執行。 版本是不可變的,這表示任何變更都必須建立新版本。

套用這些做法,組織已大幅演進了其寄送軟體的方式。 許多已從每季版本移至隨選更新。 目標是在開發週期中早期攔截問題,因為它們較不昂貴而無法修正。 整合之間的持續時間越長,解決的成本就越高的問題。 在整合程式中一致性,小組可以更頻繁地認可程式碼變更,進而提升共同作業和軟體品質。

基礎結構即程式碼和部署自動化,以及GitHub和Azure DevOps會詳細討論DevOps