套用軟體工程系統

一旦您瞭解想要先在平臺工程 旅程中處理的問題，改善開發人員自助可能會提升到清單頂端。 開始啟用自動化自助體驗的最簡單方式之一，就是重複使用您現有的工程系統。 這些系統不僅對您和內部客戶很熟悉，還可以啟用廣泛的自動化案例，即使初始用戶體驗不美觀也一樣。

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

評估您的基底 DevOps 和 DevSecOps 做法

工程系統是您內部開發人員平臺的重要層面。 不過，如果您沒有任何系統至少以 DevOps 和 DevSecOps 的某些主要租用戶為目標，則您識別的問題可能會告訴您從該處開始。 內部開發人員平臺會從中建置，以減少涉及所有人的認知負載。

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

Microsoft 的 DevOps 資源中心 是尋找所需程式和系統類型建議的絕佳位置，因此我們不會在本節中深入討論這些建議。 這些是您前進時的重要要素。 此外，別忘了將最近的 DevSecOps 主題納入計劃，例如 容器供應鏈安全性 。

如需持續意見反應的詳細資訊，請參閱 要考慮的計量。 您也可以在 精簡應用程式平臺中深入瞭解可在可檢視性、監視和持續意見反應區域中使用的工具。

在本文中的其餘部分，我們將著重於更直接歸屬於平臺工程移動的改善：除了應用程式部署) 、程式代碼環境設定，以及不屬於應用程式開發迴圈之工具、小組資產和服務的自助式布建和組態之外，還會有自動化基礎結構布建 (。

建立您想要的已建置路徑

如果您有多個工具組已組成您的工程系統，您必須先做出一項早期決策，就是是否要在初始平臺工程工作中一併合併它們，或您是否一開始支援不同工具的串連。 在大部分情況下，在此工具星形中定義一組已修補的路徑最有效，並提供更高的彈性層級。

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

您仍然可以執行自己的動作，但以我們即將進行的方向執行... 您可以變更您想要的任何專案，但這會成為您的責任。 您擁有變更 – 您擁有尖鋒刀。 - Mark，平臺工程負責人，大型歐洲跨國零售公司

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

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

不論為何，請試著避免使用已裝訂的路徑。 推出它們的最有效方式是強調小組從中取得哪些專案，而不是透過強制採用。 由於您的內部開發人員平臺著重於讓這些完全相同的小組感到快樂，因此，對個別領導者的預算和價值壓力通常會負責其餘工作。 然後，取得正確的營銷活動，讓雙向對話在未修補的路徑上，以最佳方式進行雙向交談來切換。

使用開發人員自動化工具來改善您已建置路徑的自助

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

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

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

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

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

若要深入瞭解每個方法，請參閱使用 GitHub Actions 和 Gitflow 的 AKS 應用程式 CI/CD。

您選擇的通常是由您現有的 IaC 技能集和目標 應用程式平臺的詳細資料所驅動。 GitOps 方法較新，而且在組織之間使用 Kubernetes 作為其應用程式的基底，而提取式模型目前提供您最大的彈性，因為其可用的選項數目。 我們預期大部分的組織會混合使用這兩者。 不論如何，IaC 做法都更加熟悉，將協助您瞭解適用於進一步自動化案例的模式。

將 IaC 集中化於目錄或登錄中，以調整和改善安全性

若要跨應用程式管理和調整 IaC，您應該集中發佈 IaC 成品以供重複使用。 例如，您可以在登錄、Bicep 模組、Radius 配方或儲存在雲端原生 OCI Artifact 登錄中的 Helm 圖表中使用 Terraform 模組，例如 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 Incubation 專案比直接使用 Kubernetes 更有意見，但也簡化開發人員體驗。 描述雲端服務類型訓練課程模組可協助您瞭解不同模型的優點和缺點。 不論如何，參考集中式和管理的 IaC，而不是在來源樹狀結構中擁有完整的定義，都有顯著的優點。

以開發人員無法在治理的基本建置組塊中直接存取它們層的方式保存任何所需的布建身分識別或秘密。 例如，請考慮使用 Azure 部署環境 (ADE) 達到的角色區隔圖例。

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

開發人員或 CI/CD 管線接著可以使用 Azure CLI 或 Azure Developer 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 Advanced Security 和 GitHub CODEOWNERS 等等。 選取應用程式基礎結構、服務或工具時，請務必評估它們支援這些模式的方式。 如需調整應用程式和治理的詳細資訊，請參閱 精簡應用程式平臺。

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

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

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

Teams 即程序代碼

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

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

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

在此範例中，我們假設：

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

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

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

具體而言，CI/CD 系統：

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

請注意，如果您的組織已經使用 項目權利管理之類的專案，您可能可以省略此模式中的管理群組成員資格。

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

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

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

幸運的是，大部分的 CI 系統包括 GitHub Actions 和 Azure Pipelines，都可以使用輸入來設定工作流程，然後您可以透過其 UI 或 CLI 手動觸發。 假設開發人員和相關作業角色可能已經熟悉這些用戶體驗，手動觸發程式可以將所有專案增強為程序代碼模式，讓活動自動化 (或作業) 沒有自然檔案表示法或完全自動化，而不需要 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 上的開發容器。 通道型選項，不僅可與用戶端搭配使用，也可使用網頁型 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 之類的範本化引擎，或像是 azd () Azure Developer CLI 之類的專案，除了範本化和簡化的 CI/CD 設定之外，也提供一組方便的開發人員命令。 由於 Azure Developer CLI 可用來驅動所有案例中的環境設定，因此它會與 Azure 部署環境整合，以提供改良的安全性、整合的 IaC、環境追蹤、考慮區隔，以及簡化的 CD 設定。

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

保持正確且正確

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

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

範本內容

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

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

精簡您的應用程式平臺