套用軟體工程系統

改善開發人員自助應該是您在平臺工程 旅程中解決的第一個問題之一。

開始啟用自動化自助體驗的最簡單方式之一，就是重複使用您現有的工程系統。 這些系統不僅熟悉您和內部客戶，而且即使初始用戶體驗不美觀，也能啟用廣泛的自動化案例。

本文提供套用工程系統的秘訣，以處理更廣泛的自助案例，以及如何將最佳做法封裝到範本的詳細數據，以協助您開始正確且保持正確。

評估您的基底 DevOps 和 DevSecOps 做法

工程系統是內部開發人員平臺的重要層面。 內部開發人員平臺會從 DevOps 和 DevSecOps 的主要租使用者建立，以減少相關人員的認知負載。

DevOps 結合了開發和作業，將人員、流程和技術統一在應用程式規劃、開發、傳遞和作業中。 其旨在改善跨過去孤立角色的共同作業，例如開發、IT 作業、品質工程和安全性。 您可以在開發、部署、監視、觀察和意見反應之間建立持續迴圈。 DevSecOps 會透過整個應用程式開發程序的持續安全性作法，層層進入此迴圈。

下列各節著重於更直接歸因於平臺工程動作的改進：鋪路路徑、自動化基礎結構布建（除了應用程式部署）、編碼環境設定，以及工具、小組資產和服務，以及不屬於應用程式開發迴圈的自助布建和設定。

建立您想要的鋪路路徑

如果您有多個工具組已經組成您的工程系統，一個早期決定是要將其合併為初始平臺工程工作的一部分，或者您是否一開始就支援不同工具的星座。 在這個工具星座內定義一組鋪路路徑是最有效的，並提供更高的彈性層級。

當您開始轉向產品思維時，請將這些鋪路路徑內的工程系統視為由集中管理的工具，作為開發小組的服務。 接著，貴組織內的個別小組或部門可能會偏離，但預期會個別管理、維護及支付其工具，同時仍遵守任何合規性需求。 這可讓您在不中斷的情況下將新工具饋送至生態系統，因為您可以評估一段時間后可能納入鋪路的任何專案。 作為一個平臺工程負責人所說：

你仍然可以做自己的事， 但以我們要的方向做... 您可以變更您想要的任何內容，但這會成為您的責任。 你擁有這些變化 - 你擁有尖銳的刀。 - Mark，平臺工程主管，大型歐洲跨國零售公司

鑒於平臺工程的主要目標是將產品思維轉移到您為內部客戶提供價值的產品思維，此星座方法通常比由上而下的工作更適合。 當您建立並精簡鋪路路徑時，保留一些彈性可讓小組提供輸入，並解決特定應用程式的任何真正獨特需求，而不會影響組織中的其他人。 這導致了一組完全鋪成的黃金路徑，而其他人則只部分鋪路。 在沒有獨特需求的情況下，額外的工作開發小組會自然而然地導致他們想要隨著時間移至支持的路徑。

如果您偏好合併策略，移轉現有的應用程式可能會比您預期的工作還要多，因此若要開始，您可能想要專注於此空間的起始層面，並專注於新專案。 這提供您第一個鋪路的路徑，而現有的一切都本質上是未修補的。 未修補路徑上的開發小組接著會考慮移動，一旦您的新鋪路向組織顯示其價值。 此時，您可以執行正確的活動，讓所有人都能透過雙向溝通獲得您所需的狀態，因為開發小組將此視為權益，而不是稅金。 在活動期間，平臺工程小組可以專注於協助小組移轉，而開發小組則提供如何讓鋪路路徑變得更好的意見反應。

無論如何，請避免使用鋪路的路徑。 推出鋪路的最有效方式是強調哪些團隊擺脫他們，而不是通過強制採用。 由於您的內部開發人員平臺著重於讓這些完全相同的小組滿意、預算和時間價值壓力，讓個別領導者負責其餘工作。 然後，獲得正確的營銷活動，為那些在未修補的路徑上切換的人提供雙向對話的途徑。

使用開發人員自動化工具來改善已鋪路的自助

建立第一個鋪路路徑的一部分應該是建立核心開發人員自動化產品。 當您開始考慮啟用開發人員自助功能時，這些很重要。

在持續傳遞期間啟用自動應用程式基礎結構布建

如果尚未實作，您在規劃期間發現的問題可能會指出持續整合 （CI） 和持續傳遞 （CD） 可以協助解決的問題。 GitHub Actions、Azure DevOps、Jenkins 等產品，以及 Flux 或 Argo CD 等提取式 GitOps 解決方案都存在於此空間中。 您可以在 Microsoft DevOps 資源中心開始使用這些主題。

即使您已經實作一種方法，以在現有的基礎結構中持續部署應用程式，您也應該考慮使用 基礎結構即程序代碼 （IaC） 來建立或更新所需的應用程式基礎結構作為 CD 管線的一部分。

例如，請考慮這些圖例，其中顯示兩種使用 GitHub Actions 來更新基礎結構並部署至 Azure Kubernetes Service 的方法：一個使用推送式部署，另一個使用提取式部署（GitOps） 部署。

您選擇的是由現有的 IaC 技能集和目標 應用程式平臺的詳細資料所驅動。 GitOps 方法較新，而且在使用 Kubernetes 作為其應用程式基底的組織中很受歡迎，而提取式模型目前提供您最大的彈性，因為其可用選項數目。 我們預期大部分的組織會混合使用這兩者。 不管怎樣，在 IaC 實務中變得精通，將協助您瞭解適用於進一步自動化案例的模式。

將 IaC 集中化在目錄或登錄中以調整及改善安全性

若要跨應用程式管理和調整 IaC，您應該集中發布您的 IaC 成品以供重複使用。 例如，您可以在登錄、Bicep 模組、Radius 配方或 Helm 圖表中使用 Terraform 模組，儲存在雲端原生 OCI Artifact 登錄中的圖表，例如 Azure Container Registry （ACR）、DockerHub 或 Azure 部署環境 （ADE） 中的目錄。 針對 GitOps 和 Kubernetes，叢集 API（和 CAPZ 之類的實作）可讓您管理 Kubernetes 工作負載叢集，而 Azure 服務操作員等自定義資源定義則可為其他類型的 Azure 資源提供新增支援，其他工具，例如跨多個雲端的跨平面支持資源。 這些可讓您在類似 ACR 的案例中，使用集中式或常見的 Helm 圖表。

集中 IaC 可讓您更妥善地控制誰可以進行更新，因為它們不再與應用程式程式碼一起儲存，藉此改善安全性。 當專家、作業或平臺工程師進行所需的變更時，程式代碼更新期間發生意外變更所造成的意外中斷風險較小。 開發人員也受益於這些建置組塊，因為它們不需要自行撰寫完整的 IaC 範本，並自動受益於編碼的最佳做法。

您選擇的 IaC 格式取決於您現有的技能集、您需要的控制層級，以及您使用的應用程式模型。 例如 ，Azure Container Apps （ACA） 和最近的實驗 性 Radius OSS 孵化專案比直接使用 Kubernetes 更有意見，但也簡化開發人員體驗。 描述雲端服務類型訓練模組可協助您瞭解不同模型的優缺點。 不管怎樣，參考集中式和管理的 IaC，而不是在來源樹狀結構中擁有完整的定義，都有顯著的優點。

以開發人員無法在治理的基本建置組塊中直接存取這些身分識別或秘密的方式保存任何必要的布建身分識別或秘密。 例如，請考慮此圖例，說明您可以使用 Azure 部署環境 （ADE） 達成的角色區隔。

在這裡，平台工程師和其他專家會開發 IaC 和其他範本，並將其放在目錄中。 接著，作業可以藉由「環境類型」新增受控識別和訂用帳戶，並指派允許他們用來布建的開發人員和其他使用者。

開發人員或 CI/CD 管線接著 可以使用 Azure CLI 或 Azure 開發人員 CLI 來布建預先設定和控制的基礎結構，甚至不需要存取基礎訂用帳戶或身分識別才能這麼做。 無論您是否使用類似 ADE 的內容，您選擇的持續傳遞系統都可以藉由將秘密和來源 IaC 內容與開發人員無法自行存取或修改的位置分開，以協助您安全地更新基礎結構。

在應用程式持續傳遞以外的案例中啟用自助

雖然 CI 和 CD 概念會系結至應用程式開發，但內部客戶想要布建的許多專案不會直接系結至特定應用程式。 這可以是共用基礎結構、建立存放庫、布建工具等等。

若要瞭解這可能有所説明的位置，請思考您目前擁有手動或服務台型程式的位置。 針對每個問題，請考慮下列問題：

• 此程式發生的頻率為何？
• 程式是否緩慢、容易發生錯誤，或需要大量工作才能達成？
• 這些程式會因為必要的核准步驟或只是缺乏自動化而手動進行嗎？
• 核准者是否熟悉原始檔控制系統和提取要求程式？
• 程式的稽核需求為何？ 這些與原始檔控制系統的稽核需求有何不同？
• 在移至更複雜的程式之前，您是否可以先從風險較低的程序開始？

將頻繁、高投入或容易出錯的程序識別為先自動化的潛在目標。

使用所有項目作為程序代碼模式

除了 Git 無處不在之外，Git 的其中一個好事是它是一個安全的、可稽核的資訊來源。 除了認可歷程記錄和訪問控制之外，提取要求和分支保護等概念還提供一種方式，以建立特定檢閱者、交談歷程記錄，或自動檢查，這些檢查必須在合併至主要分支之前通過。 結合 CI/CD 系統中找到的彈性工作引擎時，您有安全的自動化架構。

程序代碼一切背後的概念是，您可以將幾乎所有項目轉換成安全 Git 存放庫中的檔案。 然後，連接到存放庫的不同工具或代理程式可以讀取內容。 將一切視為程式代碼可透過範本化來協助重複性，並簡化開發人員自助。 讓我們逐步解說一些如何運作的範例。

將 IaC 模式套用至任何基礎結構

雖然 IaC 很受歡迎，可協助自動化應用程式傳遞，但模式會延伸到您可能想要布建和設定的任何基礎結構、工具或服務，而不只是系結至特定應用程式的基礎結構、工具或服務。 例如，與已安裝 Flux 的叢集共用 K8、布建多個小組和應用程式所使用的 DataDog，或甚至設定您最愛的共同作業工具。

其運作方式是，您有個別且 安全的 集中式存放庫，其中包含一系列檔案，這些檔案代表應該布建和設定的內容（在此案例中，從 Bicep、Terraform 到 Helm 圖表和其他 Kubernetes 原生格式的任何專案）。 作業小組或其他一組系統管理員擁有存放庫，而開發人員（或系統）可以提交提取要求。 將這些 PR 合併到這些系統管理員的主要分支後，應用程式開發期間所使用的相同 CI/CD 工具就可以開始處理變更。 請考慮此圖例，其使用 Azure 部署環境中所儲存的 GitHub Actions 和 IaC 和部署身分識別：

如果您已經使用 GitOps 方法來部署應用程式，您也可以重複使用這些工具。 結合 Flux 和 Azure 服務操作員等工具，可讓您擴充 Kubernetes 外部：

不論是哪一種情況，您都有完全受控、可重現且可稽核的資訊來源，即使產生的不是應用程式。 如同應用程式開發，您需要的任何秘密或受控識別會儲存在管線/工作流程引擎或布建服務的原生功能中。

由於製作PR的人員無法直接存取這些秘密，因此它為開發人員提供了一種方式，讓開發人員安全地起始他們無權自行執行的動作。 這可讓您遵守最低許可權原則，同時仍為開發人員提供自助選項。

追蹤布建的基礎結構

當您開始調整此方法時，請考慮您想要如何追蹤已布建的基礎結構。 您的 Git 存放庫是組態的真相來源，但不會告訴您所建立專案的特定 URI 和狀態資訊。 不過，遵循一切作為程序代碼方法，可讓您利用資訊來源來合成已布建基礎結構的清查。 您的布建者可能也是您可以利用這項資訊的良好來源。 例如，Azure 部署環境包含開發人員可查看的環境追蹤功能。

若要深入瞭解如何追蹤各種數據源，請參閱 設計開發人員自助基礎。

將安全性套用為程序代碼，並將原則套用為程序代碼模式

雖然布建基礎結構很有用，但請確定這些環境是安全的，而且通常遵循貴組織的原則同樣重要。 這導致了“政策即程序代碼”概念的興起。 在這裡，原始檔控制存放庫中的組態檔可用來執行磁碟驅動器安全性掃描或套用基礎結構原則等動作。

許多不同的產品和 開放原始碼 專案都支援此方法，包括 Azure 原則、開放原則代理程式、GitHub 進階安全性，以及 GitHub CODEOWNERS 等。 選取您的應用程式基礎結構、服務或工具時，請務必評估它們支援這些模式的方式。 如需精簡應用程式和控管的詳細資訊，請參閱 精簡您的應用程式平臺。

針對您自己的案例使用所有項目作為程序代碼

程序代碼一切會將這些模式延伸至 IaC 以外的各種自動化和設定工作。 它不僅可支援建立或設定任何類型的基礎結構，還可以更新任何下游系統中的數據或觸發工作流程。

PR 會成為各種不同程式的良好基準自助用戶體驗，特別是當您開始使用時。 程式自然會獲得 Git 本身所提供的安全性、可稽核性和復原優點，而所涉及的系統也可以隨著時間而變更，而不會影響用戶體驗。

Teams 即程序代碼

將所有項目當成程式代碼套用至您自己的案例的其中一個範例是小組即程序代碼模式。 組織會套用此模式來標準化小組成員資格，而在某些情況下，開發人員工具/服務權利橫跨各種不同的系統。 此模式可消除手動上線和下線服務台程式，這些程式是由系統開發人員和操作員存取自己的群組、使用者和存取概念所驅動。 手動服務台程式是潛在的安全性風險，因為它有可能過度布建存取。 使用小組作為程式代碼模式時，Git 和提取要求的組合可以從可稽核的數據源啟用自助。

如需此模式成熟、廣泛變化的範例，請參閱 GitHub 的部落格文章，以瞭解其如何管理權利。 GitHub 也開放原始碼其複雜的 權利實 作，讓您試用或採用。 雖然部落格文章說明所有員工的權利，但您可以將小組當做程式代碼概念套用至範圍更窄的開發小組案例。 這些開發小組可能根本不會在員工組織圖表中表示，而且牽涉到可能會使上線或下線小組成員複雜化專屬的工具或服務。

以下是此概念簡化變化的摘要，該概念使用 CI/CD 系統和識別提供者群組來協調更新：

在此範例中：

• 每個涉及的系統都已設定為使用您的身分識別提供者（例如 ，Microsoft Entra ID）進行單一登錄 （SSO）。
• 您將跨系統使用身分識別提供者群組（例如 Entra 群組）來管理角色成員資格，以減少複雜性並維護集中式稽核。

概括而言，此模式的運作方式如下：

• 鎖定的中央 Git 存放庫中有一組 （通常是 YAML） 檔案，代表每個抽象小組、相關的使用者成員資格和使用者角色。 小組變更的擁有者或核准者也可以儲存在此相同位置（例如，透過 CODEOWNERS）。 這些檔案中用戶的參考是識別提供者，但此存放庫會作為這些小組的真相來源（但不是使用者）。
• 這些檔案的所有更新都是透過提取要求完成。 這會將交談和相關參與者系結至 Git 認可的要求，以取得稽核性。
• 潛在客戶和個別使用者可以讓PR新增/移除人員，而開發潛在客戶和其他角色可以使用具有範本中新小組檔案的PR來建立新的小組。
• 每當 PR 合併為 main 時，系結至存放庫的 CI/CD 系統會視需要更新身分識別提供者系統和所有下游系統。

具體來說，CI/CD 系統：

• 使用適當的識別提供者系統 API，建立或更新每個角色的身分識別提供者群組，與檔案中的個人完全一樣（不再如此，不少）。
• 使用每個下游系統的 API，將這些系統群組概念系結至每個角色的識別提供者群組（例如： GitHub 和 Azure DevOps）。 這可能會導致小組與下游系統之間的一對多關係來代表角色。
• （選擇性）針對每個下游系統使用 API 來實作系結至系統群組機制的許可權邏輯。
• 使用 API 以結果來更新鎖定的數據存放區（包括關聯下游系統小組識別碼），然後可供任何內部建置系統取用。 您也可以視需要儲存相同識別提供者用戶帳戶/帳戶之不同系統標識碼之系統表示法的關聯。

如果您的組織已經使用如 Entra Entitlement Management 之類的專案，您可能可以省略此模式中的管理群組成員資格。

您的需求和原則可能會變更細節，但一般模式可以調整為任意數目的變化。 與任何下游系統整合所需的任何秘密，都是在 CI/CD 系統中維護（例如，在 GitHub Actions、Azure Pipelines 中），或類似 Azure 金鑰保存庫。

使用手動或外部觸發的參數化工作流程

您識別的一些自助相關問題可能不利於在 Git 中使用檔案。 或者，您可能有想要用來驅動自助體驗的使用者介面。

幸運的是，大部分的 CI 系統，包括 GitHub Actions 和 Azure Pipelines，都可以使用輸入來設定工作流程，然後您可以透過 UI 或 CLIS 手動觸發。 由於開發人員和相關作業角色可能已經熟悉這些用戶體驗，手動觸發程式可以將所有專案增強為程式代碼模式，以啟用沒有自然檔案表示法或完全自動化的活動（或作業）自動化，而不需要 PR 程式。

CI 系統可讓您選擇透過 API 從您自己的用戶體驗觸發這些工作流程或管線。 針對 GitHub Actions，進行這項工作的關鍵是 動作 REST API，用來引發工作流程分派事件 來觸發工作流程執行。 Azure DevOps 觸發程式 很類似，您也可以使用 Azure DevOps Pipeline API 來執行。 您可能會在其他產品中看到相同的功能。 無論是手動觸發還是透過 API 觸發，每個工作流程都可以藉由將workflow_dispatch組態新增至工作流程 YAML 檔案來支援一組輸入。 例如，這是入口網站工具組，例如 Backstage.io 與 GitHub Actions 互動 的方式。

CI/CD 系統的工作流程或作業系統無疑會追蹤活動、回報返回狀態，以及開發人員和作業小組都可用來查看出問題的詳細記錄。 如此一來，就如同程序代碼模式一樣，它具有一些與所有專案相同的安全性、可稽核性和可見度優勢。 不過，請記住，這些工作流程或管線執行的任何動作，看起來就像系統身分識別（例如，Microsoft Entra ID 中的服務主體或受控識別）到下游系統。

您將能看見誰在 CI/CD 系統中起始要求，但您應該評估這是否足夠資訊，並確定您的 CI/CD 保留設定符合稽核需求，以取得此資訊很重要的情況。

在其他情況下，您與整合的工具可能會有自己的追蹤機制，您可以依賴這些機制。 例如，這些 CI/CD 工具幾乎一律有數個 通知機制可供使用，例如使用 Microsoft Teams 或 Slack 通道，這可讓您讓任何提交要求以取得狀態更新的任何人，而通道會提供所發生情況的非正式記錄。 這些相同的工作流程引擎通常已設計為與作業工具整合，以進一步擴充這些模式的實用性。

總而言之，您可以使用儲存在原始檔控制存放庫中的檔案來實作一些自動化，這要歸功於 CI/CD 工具的彈性及其現成的用戶體驗。 若要查看內部開發人員平臺如何使用此方法作為起點，而不需在一段時間內危害更複雜的功能，請參閱 設計開發人員自助基礎。

自動設定開發人員程式代碼環境

工程系統中的另一個常見問題是開發人員撰寫環境啟動載入和正規化。 以下是您可能會在此領域聽到的一些常見問題：

• 在某些情況下，開發人員可能需要數周的時間才能取得其第一個提取要求。 當您在功能人員與專案之間轉移開發人員相當頻繁（例如，在矩陣式組織中）、需要增加承包商，或是在僱用階段的小組時，這是一個有問題的領域。
• 開發人員與 CI 系統之間的不一致可能會導致經常「它在我的電腦上運作」問題，即使是經驗豐富的小組成員也是如此。
• 實驗和升級架構、運行時間和其他軟體也可以中斷現有的開發人員環境，並導致失去時間嘗試找出究竟出了什麼問題。
• 針對開發潛在客戶，程式代碼檢閱可能會降低開發速度，因為它們可能需要進行設定變更，以便在檢閱完成後加以復原。
• 小組成員和操作員還必須花時間增加開發以外的相關角色（操作員、QA、業務、贊助者）來協助測試、查看進度、訓練業務角色，並宣傳團隊正在執行的工作。

您鋪路的一部分

若要協助解決這些問題，請考慮將特定工具和公用程式設定為妥善定義的鋪路路徑的一部分。 編寫開發人員計算機設定的腳本有助於，而且您可以在 CI 環境中重複使用這些相同的腳本。 不過，請考慮支援容器化或虛擬化的開發環境，因為它們可以提供的優點。 您可以事先設定這些程式碼撰寫環境，以取得您組織的或項目的規格。

工作站更換和目標 Windows

如果您是以 Windows 為目標，或想要執行完整的工作站虛擬化（除了專案特定設定之外，還有用戶端工具和主機 OS 設定），VM 通常會提供最佳功能。 這些環境對於從 Windows 用戶端開發到 Windows 服務或管理和維護 .NET 完整架構 Web 應用程式的任何專案都很有用。

方法	範例
使用雲端裝載的 VM	Microsoft Dev Box 是完整的 Windows 工作站虛擬化選項，內建整合至桌面管理軟體。
使用本機 VM	Hashicorp Vagrant 是不錯的選擇，您可以使用 HashiCorp Packer 來建置其和開發 Box 的 VM 映射。

工作區虛擬化和目標為Linux

如果您是以 Linux 為目標，請考慮使用工作區虛擬化選項。 這些選項著重於取代您的開發人員桌面，以及更多專案或應用程式特定工作區。

方法	範例
使用雲端裝載的容器	GitHub Codespaces 是開發容器的雲端式環境，可支援與 VS Code、JetBrains 的 IntelliJ 和終端機型工具整合。 如果這項或類似的服務不符合您的需求，您可以使用 VS Code 的 SSH 或 遠端通道 支援搭配遠端 Linux VM 上的開發容器。 通道型選項，它不僅適用於用戶端，而且適用於 Web 型 vscode.dev。
使用本機容器	如果您想要改用本機開發容器選項，或除了裝載雲端選項之外，開發容器在 VS Code 中具有穩固的支援、IntelliJ 的支援，以及其他工具和服務。
使用雲端裝載的 VM	如果您發現容器太限制，VS Code 或 JetBrains 等工具中的 SSH 支援可讓您直接連線到您自己管理的 Linux VM。 VS Code 也有 通道型選項 可在這裡運作。
使用 Windows 子系統 Linux 版	如果您的開發人員完全位於 Windows 上，Windows 子系統 Linux 版 （WSL） 是讓開發人員在本機以 Linux 為目標的絕佳方式。 您可以匯出小組的 WSL 散發套件，並與所有設定項目共用。 針對雲端選項，Microsoft Dev Box 等雲端工作站服務也可以利用 WSL 來鎖定 Linux 開發。

建立包含保持正確設定的起始正確應用程式範本

程序代碼模式中所有項目的絕佳之處在於，它可以讓開發人員在從頭開始建立的鋪路路徑上。 如果這對組織而言是一項挑戰，應用程式範本可能會快速成為重複使用建置組塊以推動一致性、促進標準化及編纂組織最佳做法的重要方式。

首先，您可以使用與 GitHub 範本存放庫一樣簡單的專案，但如果貴組織遵循 monorepo 模式，這可能較不有效。 您也可以建立範本，以協助設定與應用程式來源樹狀結構不直接相關的專案。 相反地，除了範本化和簡化的 CI/CD 設定之外，您也可以使用 Cookiecutter、Yeoman 之類的範本化引擎，或 Azure 開發人員 CLI （azd） 之類的範本化引擎，也提供一組方便的開發人員命令。 由於 Azure 開發人員 CLI 可用於在所有案例中驅動環境設定，因此它會與 Azure 部署環境整合，以提供改良的安全性、整合式 IaC、環境追蹤、考慮區隔，以及簡化的 CD 設定。

一旦您有一組範本，開發人員潛在客戶就可以使用這些命令行工具或其他整合式用戶體驗，為其應用程式建構其內容。 不過，由於開發人員可能無權從範本建立存放庫或其他內容，這也是使用手動觸發、參數化工作流程/管線的另一個機會。 您可以設定輸入，讓 CI/CD 系統代表其建立從存放庫到基礎結構的任何專案。

保持正確和正確

不過，為了協助調整，這些應用程式範本應該儘可能參考集中式建置組塊（例如 IaC 範本，甚至是 CI/CD 工作流程/管線）。 事實上，將這些集中式建置組塊視為自己的起始正確範本形式，可能是解決您識別的一些問題的有效策略。

每個個別範本都不僅可以套用至新的應用程式，也可以套用到您想要更新的現有範本，作為推出更新或改進指導方針的正確行銷活動的一部分。 更棒的是，此集中化可協助您讓新的和現有的應用程式保持正確狀態，讓您隨著時間發展或擴充最佳做法。

範本內容

建議您在建立範本時考慮下列區域。

區域	詳細資料
足以驅動應用程式模式、SDK 和工具使用的範例原始程式碼	包含程式代碼和設定，引導開發人員使用建議的語言、應用程式模型和服務、API、SDK 和架構模式。 請務必使用您選擇的工具來包含分散式追蹤、記錄和可觀察性的程序代碼。
建置和部署腳本	提供開發人員觸發組建和本機/沙箱部署的常見方式。 包含 IDE 內/編輯器偵錯組態，以供您選擇的工具使用。 這是避免維護頭痛並防止 CI/CD 同步處理的重要方式。如果您的範本化引擎類似 Azure 開發人員 CLI，可能已經有 您可以直接使用的命令。
CI/CD 的設定	根據您的建議，提供工作流程/管線來建置和部署應用程式。 利用集中式、 可重複使用或 範本化 工作流程/管線，協助保持最新狀態。 事實上，這些可重複使用的工作流程/管線可以自行啟動正確的範本。 請務必考慮手動觸發這些工作流程的選項。
基礎結構即程式代碼資產	提供建議的 IaC 組態， 包括集中管理的模組或目錄項目的 參考，以確保任何基礎結構設定都遵循 get-go 的最佳做法。 這些參考也可以協助小組在時間進行時保持正確。 結合工作流程/管線，您也可以包含 IaC 或 EaC 來 布建任何專案。
安全性與原則作為程式代碼資產	DevSecOps 移動會將安全性設定移至程式代碼中，這非常適合範本。 某些原則即程序代碼成品也可以在應用層級套用。 包含在 GitHub 進階安全性中，從 CODEOWNERS 等檔案到掃描設定的所有專案，例如 dependabot.yaml。 提供排程的工作流程/管線執行，以使用類似 適用於雲端的 Defender 以及環境測試回合等專案進行掃描。 對於供應鏈安全性而言，這很重要，除了應用程式套件和程序代碼之外，請務必 考慮容器映像 。 這些步驟可協助開發小組保持正確。
可檢視性、監視和記錄	啟用自助的一部分，就是在部署應用程式後提供輕鬆的可見度。 除了運行時間基礎結構之外，請務必包含可觀察性和監視的設定。 在大部分情況下，有一個 IaC 層面可以設定（例如代理程式部署、檢測），而在其他人中，它可能是另一種類型的設定即程式代碼成品（例如，監視 Azure 應用程式 Insights 的儀錶板）。 最後，請務必使用您選擇的工具來包含分散式追蹤、記錄和可觀察性的程式碼範例程序代碼。
撰寫環境設定程序代碼	包含用於編碼 linters、formatter、editors 和 IDE 的組態檔。 包含設定腳本，以及工作區或工作站虛擬化檔案，例如 devcontainer.json、 devbox.yaml、開發人員專注的 Dockerfiles、Docker Compose 檔案或 Vagrantfiles。
測試組態	使用慣用的服務，提供單元和更深入的測試組態檔，例如適用於UI或 Azure 負載測試Microsoft Playwright Testing。
共同作業工具設定	如果您的問題管理和原始檔控制系統支援工作/問題/PR 範本作為程序代碼，也包含這些範本。 在需要更多設定的情況下，您可以選擇性地提供工作流程/管線，以使用可用的 CLI 或 API 來更新系統。 這也可讓您設定其他共同作業工具，例如 Microsoft Teams 或 Slack。

相關內容

• Microsoft的 DevOps 資源中心
• 容器供應鏈安全性
• 使用 GitHub Actions 和 Gitflow 的 AKS 應用程式 CI/CD

精簡您的應用程式平臺