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