改善開發人員自助服務應該是您在 平台工程旅程中解決的首要問題之一。
開始啟用自動化自助服務體驗的最簡單方法之一是重複使用現有的工程系統。 這些系統不僅為您和您的內部客戶所熟悉，而且即使最初的使用者體驗並不漂亮，它們也可以實現廣泛的自動化場景。
本文提供套用工程系統以處理更廣泛的自助服務案例的秘訣，以及如何將最佳做法封裝成範本的詳細資料，以協助您正確開始並保持正確。
評估您的基本 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 構件以供重複使用。 例如，您可以在登錄中使用 Terraform 模組、Bicep 模組、Radius 配方或儲存在雲端原生 OCI 成品登錄中的 Helm 圖表，例如 Azure Container Registry （ACR）、DockerHub 或 Azure 部署環境 （ADE） 中的目錄。 針對 GitOps 和 Kubernetes， 叢集 API （和 CAPZ 等實作） 可讓您管理 Kubernetes 工作負載叢集，而 Azure 服務操作員 等自訂資源定義可以為其他類型的 Azure 資源提供額外的支援。 其他工具 （ 例如 Crossplane ） 支援跨多個雲端的資源。 這些可讓您在 ACR 等專案中使用集中式或通用 Helm 圖表，以處理更廣泛的案例。
集中化 IaC 可讓您更好地控制誰可以進行更新，因為它們不再與應用程式程式碼一起儲存，從而提高了安全性。 當專家、營運或平台工程師進行必要的變更時，程式碼更新期間因意外變更而導致意外中斷的風險較小。 開發人員也可以從這些建置區塊中受益，因為他們不必自己編寫完整的 IaC 範本，並自動從編碼的最佳實踐中受益。
您選擇的 IaC 格式取決於您現有的技能集、所需的控制層級，以及您使用的應用程式模型。 例如， Azure 容器應用程式 （ACA） 和最近的實驗性 Radius OSS 孵化專案比直接使用 Kubernetes 更固執己見，但也簡化了開發人員體驗。 若要瞭解不同模型的優缺點，請參閱 描述雲端服務類型。 無論如何，引用集中式和託管的 IaC 而不是在源樹中擁有完整的定義具有顯著的好處。
以無法讓開發人員直接存取的方式保存任何必要的配置身分或秘鑰，這樣做為治理提供了基本的構建基礎。 例如，請考慮此圖解您可以使用 Azure 部署環境 （ADE） 來達成的角色區隔。
在這裡，平台工程師和其他專家開發 IaC 和其他模板並將它們放置在目錄中。 然後，作業可以依 環境類型 新增受控識別和訂用帳戶，並指派允許使用它們進行佈建的開發人員和其他使用者。
然後，開發人員或您的 CI/CD 管線可以使用 Azure CLI 或 Azure 開發人員 CLI 來佈建預先設定和受控的基礎結構，甚至無法存取執行此動作所需的基礎訂用帳戶或身分識別。 無論您是否使用 ADE 之類的東西，您選擇的持續交付系統都可以通過分離秘密並從開發人員無法自行訪問或修改的位置獲取 IaC 內容來幫助您安全可靠地更新基礎設施。
在應用程式持續交付以外的案例中啟用自助服務
雖然 CI 和 CD 概念與應用程式開發相關，但內部客戶想要佈建的許多專案並不直接與特定應用程式相關。 這可以是共用基礎結構、建立儲存庫、佈建工具等等。
若要瞭解這可能有所幫助的地方，請考慮您目前在哪裡有手動或服務台型流程。 對於每個問題，請思考以下問題：
- 這個過程多久發生一次？
- 該過程是否緩慢、容易出錯或需要大量工作才能實現？
- 這些流程是由於所需的審批步驟而手動的還是僅僅缺乏自動化？
- 核准者是否熟悉原始檔控制系統和提取請求流程？
- 流程的審核要求是什麼？ 這些是否與您的原始檔控制系統的稽核需求不同？
- 在轉向更複雜的流程之前，您是否可以先從風險較低的流程開始？
將頻繁、高工作量或容易出錯的流程識別為首先自動化的潛在目標。
使用「一切皆代碼」模式
Git 除了無處不在之外，還有一個好處是它旨在成為一個安全、可審計的資訊來源。 除了提交歷程記錄和存取控制之外，拉取請求和分支保護等概念也提供一種方法來建立特定檢閱者、討論歷程，以及及/或在合併到主分支之前必須通過的自動檢查。 當與 CI/CD 系統中的靈活任務引擎結合使用時，您就擁有了一個安全的自動化框架。
所有內容即代碼背後的想法是，您幾乎可以將任何內容轉換為安全 Git 存儲庫中的文件。 然後，連線到儲存庫的不同工具或代理程式可以讀取內容。 將所有內容視為程式碼有助於透過範本實現可重複性，並簡化開發人員自助服務。 讓我們來看看這是如何工作的幾個例子。
將 IaC 模式套用至任何基礎結構
雖然 IaC 因幫助自動化應用程式交付而廣受歡迎，但該模式擴展到您可能想要佈建和配置的任何基礎設施、工具或服務，而不僅僅是與特定應用程式相關的基礎設施、工具或服務。 例如，安裝了 Flux 的共用 Kubernetes 叢集、佈建多個團隊和應用程式使用的 DataDog 等專案，甚至設定您最喜歡的協作工具。
其運作方式是，您有一個 個別的安全集中 式存放庫，其中包含一系列代表應佈建和設定的內容的檔案 （在此案例中，從 Bicep 或 Terraform，到 Helm 圖表和其他 Kubernetes 原生格式）。 作業小組或其他系統管理員集擁有存放庫，而開發人員 （或系統） 可以提交提取要求 （PR）。 一旦這些系統管理員將這些 PR 合併到主分支中，應用程式開發期間使用的相同 CI/CD 工具就可以啟動來處理變更。 請考慮下圖，其中顯示位於 Azure 部署環境中的 GitHub Actions、IaC 和部署身分識別：
如果您已經使用 GitOps 方法進行應用程式部署，您也可以重複使用這些工具。 結合 Flux 和 Azure 服務操作員 等工具，可讓您在 Kubernetes 之外展開：
無論哪種情況，您都有完全受管理、可重現且可稽核的資訊來源，即使產生的內容不是針對應用程式。 如同應用程式開發，您需要的任何秘密或受控識別都會儲存在管線/工作流程引擎或布建服務的原生功能中。
由於製作 PR 的人無法直接存取這些秘密，因此它為開發人員提供了一種安全啟動他們自己沒有直接權限的操作的方法。 這使您可以遵守最小權限原則，同時仍為開發人員提供自助服務選項。
追蹤佈建的基礎結構
當您開始擴展此方法時，請考慮您要如何追蹤已佈建的基礎設施。 您的 Git 存放庫是組態的真實來源，但不會告訴您有關您建立的內容的特定 URI 和狀態資訊。 不過，遵循一切即程式碼方法可讓您利用資訊來源來綜合佈建基礎結構的清單。 您的供應者也可能是您可參考的此資訊的可靠來源。 例如，Azure 部署環境包含開發人員可以查看的環境追蹤功能。
若要深入瞭解如何跨各種資料來源進行追蹤，請參閱 設計開發人員自助服務基礎。
將安全性套用為程式碼，並將原則套用為程式碼型樣
雖然佈建基礎結構很有用，但確保這些環境安全且通常遵循組織的原則也同樣重要。 這導致了 政策即代碼 概念的興起。 在這裡，原始檔控制儲存庫中的設定檔可用於執行磁碟機安全掃描或套用基礎結構原則等操作。
許多不同的產品和開放原始碼專案都採用了這種方法，包括 Azure Policy、 Open Policy Agent、 GitHub Advanced Security 和 GitHub CODEOWNERS 等。 選取應用程式基礎架構、服務或工具時，請務必評估它們對這些模式的支援程度。 如需精簡應用程式和治理的詳細資訊，請參閱 精簡您的應用程式平台。
將所有內容用作您自己的場景的代碼
Everything as Code 將這些模式擴展到 IaC 以外的各種自動化和配置任務。 它不僅可以支援建立或配置任何類型的基礎設施，還可以支援在任何下游系統中更新資料或觸發工作流程。
PR 會成為各種不同程式的良好基準自助式使用者體驗，尤其是在您剛開始時。 這些流程自然會獲得 Git 本身提供的安全性、可稽核性和回滾優勢，而且所涉及的系統也可以隨著時間的推移而改變，而不會影響使用者體驗。
團隊如同程式碼
將所有內容作為程式碼套用至您自己的案例的一個範例是團隊作為程式碼模式。 組織應用此模式來標準化團隊成員資格，在某些情況下，還可以跨各種系統標準化開發人員工具/服務權利。 這個模式排除了手動啟用和停用桌面支援流程，這些流程是因系統開發人員和操作者需要訪問其群組化、用戶及存取概念而驅動的。 手動服務台程式是潛在的安全性風險，因為可能會過度佈建存取權。 使用小組作為程式碼模式時，Git 和 PR 的組合可以從可稽核的資料來源啟用自助服務。
如需此模式成熟、廣泛變化的範例，請參閱 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 利用結果（包括關聯下游系統團隊 ID）更新安全鎖定的資料庫，以便接著可以用於任何內部建置的系統。 如有需要，您也可以在此儲存相同身分識別提供者用戶/帳戶之用戶 ID 的不同系統表示的關聯。
如果您的組織已經使用 Entra 權利管理之類的東西，您也許可以從此模式中省略管理群組成員資格。
您的需求和政策可能會改變細節，但一般模式可以適應任意數量的變化。 與任何下游系統整合所需的任何秘密都會維護在 CI/CD 系統中 （例如，在 GitHub Actions 或 Azure Pipelines） 中，或 Azure Key Vault 之類的專案中。
使用手動或外部觸發的參數化工作流程
您識別到的一些自助服務相關問題可能不利於在 Git 中使用檔案。 或者，您可能有一個使用者介面想要用來驅動自助服務體驗。
幸運的是，大部分的 CI 系統 （包括 GitHub Actions 和 Azure Pipelines） 都能夠設定輸入的工作流程，然後您可以透過其 UI 或 CLI 手動觸發。 鑑於開發人員和相關作業角色可能已經熟悉這些使用者體驗，手動觸發程式可以增強 Everything as Code Pattern，以啟用沒有自然檔案表示法或應該完全自動化而不需要 PR 程式的活動 （或作業） 的自動化。
您的 CI 系統可能允許您選擇透過 API 從您自己的使用者體驗觸發這些工作流程或管線。 對於 GitHub Actions，要使這項功能運作的關鍵在於使用 Actions REST API 來引發工作流程觸發事件，從而觸發工作流程運行。 Azure DevOps 觸發程式 類似，您也可以使用 Azure DevOps 管線 API 進行執行。 您可能會在其他產品中看到相同的功能。 無論是手動觸發還是透過 API 觸發，每個工作流程都可以透過將 workflow_dispatch 組態新增至工作流程 YAML 檔案來支援一組輸入。 例如，這就是入口網站工具組 （例如 Backstage.io） 與 GitHub Actions 互動 的方式。
您的 CI/CD 系統的工作流程或工作系統無疑會追蹤活動、報告狀態，並具有開發人員和營運團隊都可以使用的詳細日誌來查看問題所在。 如此一來，它具有一些與 everything as code pattern 相同的安全性、可審核性和可見性優勢。 不過，要記住的一件事是，這些工作流程或管線所執行的任何動作對下游系統而言，被視為系統身分識別（例如，Microsoft Entra ID 中的服務主體或受控識別）。
您將可以看到誰在 CI/CD 系統中起始請求，但您應該評估這是否足夠資訊，並確保您的 CI/CD 保留設定符合此資訊至關重要時的稽核需求。
在其他情況下，您整合的工具可能有自己的追蹤機制，您可以信賴。 例如，這些 CI/CD 工具幾乎總是有數種可用的通知機制，例如使用 Microsoft Teams 或 Slack 頻道，這可以讓您讓任何提交請求以獲取狀態更新的人，並且該頻道提供所發生情況的非正式記錄。 這些相同的工作流程引擎通常已經設計為與操作工具集成，以進一步擴展這些模式的實用性。
總之，由於 CI/CD 工具的靈活性及其開箱即用的使用者體驗，您可以使用儲存在原始檔控制儲存庫中的檔案來實現一些自動化。 若要瞭解內部開發人員平臺如何使用此方法作為起點，而不會隨著時間影響更複雜的功能，請參閱 設計開發人員自助服務基礎。
自動化設定開發人員編碼環境
工程系統中的另一個常見問題之一是開發人員程式編寫環境的建立和標準化。 以下是您可能在該領域聽到的一些常見問題：
- 在某些情況下，開發人員可能需要數週時間才能提交他們的第一个 pull request（提取請求）。 當您在功能小組和專案之間相當頻繁地調動開發人員時（例如，在矩陣式組織中）、需要使承包商更快融入，或是團隊處於招聘階段時，這是一個有問題的領域。
- 開發人員之間和 CI 系統之間的不一致可能會導致頻繁的「它在我的機器上運作」問題，即使對於經驗豐富的團隊成員也是如此。
- 實驗和升級框架、運行時間和其他軟件也可能破壞現有的開發人員環境，並導致浪費時間試圖找出到底出了什麼問題。
- 對於開發主管來說，程式碼審查可能會減慢開發速度，因為他們可能需要更改配置來測試並在審查完成後復原它們。
- 團隊成員和操作員還必須花時間增加開發之外的相關角色（操作員、QA、業務、贊助商），以幫助測試、查看進度、培訓業務角色並宣傳團隊正在做的工作。
部分鋪砌的道路
為了幫助解決這些問題，請考慮將特定工具和實用程式設定為明確定義的鋪砌路徑的一部分。 編寫開發人員機器設定指令碼可以提供協助，而且您可以在 CI 環境中重複使用這些相同的指令碼。 不過，請考慮支援容器化或虛擬化開發環境，因為它們可以提供好處。 這些編碼環境可以根據您組織或專案的規格預先設定。
更換工作站並以 Windows 為目標
如果您以 Windows 為目標，或想要執行完整的工作站虛擬化 （除了專案特定設定之外，用戶端工具和主機作業系統設定） ，VM 通常會提供最佳功能。 這些環境可用於從 Windows 用戶端開發到 Windows 服務或管理和維護 .NET 完整架構 Web 應用程式的任何專案。
| 方法 | 範例 |
|---|---|
| 使用雲端裝載的 VM | Microsoft Dev Box 是一個完整的 Windows 工作站虛擬化選項，內置了與桌面管理軟件的集成。 |
| 使用本機虛擬機器 | Hashicorp Vagrant 是一個不錯的選擇，您可以使用 HashiCorp Packer 為它和 Dev Box 構建 VM 映像。 |
工作空間虛擬化與鎖定Linux系统
如果您以 Linux 為目標，請考慮工作區虛擬化選項。 這些選項較少著重於取代開發人員桌面，而更著重於專案或應用程式特定工作區。
| 方法 | 範例 |
|---|---|
| 使用雲端裝載容器 | GitHub Codespaces 是開發容器的雲端式環境，支援與 VS Code、JetBrains 的 IntelliJ 和終端機型工具整合。 如果此服務或類似服務不符合您的需求，您可以在遠端 Linux VM 上搭配開發容器使用 VS Code 的 SSH 或 遠端通道 支援。 基於隧道的選項不僅適用於客戶端，還適用於基於 Web 的 vscode.dev。 |
| 使用本機容器 | 如果您想要本地開發容器選項，或除了雲端托管選項之外，Dev Containers 在 VS Code 中具有穩健的支援，支持 IntelliJ，以及 其他工具和服務。 |
| 使用雲端裝載的 VM | 如果您發現容器太有限，VS Code 等工具或 IntelliJ 等 JetBrains 工具中的 SSH 支援可讓您直接連線到您自己管理的 Linux VM。 VS Code 具有 基於隧道的選項 在這裡也有效。 |
| 使用適用於 Linux 的 Windows 子系統 | 如果您的開發人員僅使用 Windows，Windows Subsystem for Linux（WSL） 是讓開發人員在本地測試 Linux 的絕佳方式。 您可以匯出小組的 WSL 散發套件，並與已設定的所有專案共用。 對於雲端選項，Microsoft Dev Box 等雲端工作站服務也可以利用 WSL 來針對 Linux 開發。 |
建立包含保持正確設定的啟動正確應用程式範本
一切皆代碼模式的優點在於，它可以讓開發人員遵循您從一開始就設定的規範路徑。 如果這對您的組織來說是一個挑戰，應用程式範本可以很快成為重複使用建置區塊以推動一致性、促進標準化和編纂組織最佳實務的關鍵方式。
首先，您可以使用像 GitHub 範本儲存庫這樣簡單的東西，但如果您的組織遵循 單一儲存庫 模式，這可能會不太有效。 您也可以想要建立範本，以協助設定與應用程式來源樹狀結構不直接相關的專案。 相反地，您可以使用範本引擎，例如 cookiecutter、 Yeoman，或類似 Azure 開發人員 CLI （azd） 的引擎，除了範本化和簡化的 CI/CD 設定之外，也提供一組方便的開發人員命令。 由於 Azure 開發人員 CLI 可用來驅動所有案例中的環境設定，因此它會與 Azure 部署環境整合，以提供改善的安全性、整合的 IaC、環境追蹤、關注點的分離，以及簡化的 CD 設定。
一旦您擁有一組範本，開發人員就可以使用這些命令列工具或其他整合式使用者體驗來為其應用程式搭建其內容。 不過，由於開發人員可能沒有從範本建立存放庫或其他內容的權限，因此這也是使用手動觸發的參數化工作流程或管線的另一個機會。 您可以配置輸入項，讓您的 CI/CD 系統替您建立任何內容，從儲存庫到基礎設施。
保持正確並達到正確
不過，為了協助調整，這些應用程式範本應該盡可能參考集中式建置組塊 （例如，IaC 範本，甚至是 CI/CD 工作流程和管線） 。 事實上，將這些集中式建置區塊視為它們自己的正確開始範本形式可能是解決您已識別的一些問題的有效策略。
這些個別範本中的每一個不僅可以套用至新應用程式，也可以用於您打算更新現有應用程式，這作為更新或改善指引的確保合規活動的一部分。 更好的是，這種集中化可協助您保持新應用程式和現有應用程式的正確性，讓您能夠隨著時間的推移發展或擴展最佳實務。
範本內容
我們建議在建立範本時考慮以下領域。
| Area | 詳細資訊 |
|---|---|
| 足夠的範例原始程式碼來推動應用程式模式、SDK 和工具使用 | 包含程式碼和設定，以引導開發人員使用建議的語言、應用程式模型和服務、API、SDK 和架構模式。 請務必包含使用您選擇的工具進行分散式追蹤、記錄和可觀察性的程式碼。 |
| 建置和部署指令碼 | 為開發人員提供觸發組建和本機/沙箱部署的常見方式。 在您的 IDE/編輯器中加入除錯組態，供您選擇的工具加以使用。 這是避免維護難題並防止 CI/CD 不同步的重要方法。如果您的範本引擎像 Azure 開發人員 CLI 一樣固執己見，則可能已經有 您可以使用的命令。 |
| CI/CD 的設定 | 根據您的建議提供工作流程/管線，以建置和部署應用程式。 利用集中式、可重複使用或模板化的工作流程/管道，協助保持其最新狀態。 事實上，這些可重複使用的工作流程/管道本身就可以作為模板。 請務必考慮手動觸發這些工作流程的選項。 |
| 基礎結構即程式碼資產 | 提供建議的 IaC 組態，包括 集中管理模組或目錄項目 的參考，以確保任何基礎結構設定從一開始就遵循最佳做法。 這些參考資料還能幫助團隊隨著時間的推移保持正確方向。 結合工作流程/管線，您也可以包含 IaC 或 EaC 來 佈建幾乎所有事物。 |
| 安全性和原則即程式碼資產 | DevSecOps 運動將安全配置移至程式碼中，這對於範本來說非常有用。 部分原則作為程式碼構件也可以在應用程式層次套用。 包含從 CODEOWNERS 等檔案到掃描 GitHub Advanced Security 中的 dependabot.yaml 等組態的所有內容。 使用類似 Defender 供雲端使用 的工具，提供排定的掃描工作流程/管線執行以及環境測試執行。 這對於供應鏈安全很重要，除了應用程式套件和程式碼之外，請務必考慮 容器映像 。 這些步驟可協助開發團隊保持正軌。 |
| 可觀察性、監控和記錄 | 啟用自助服務的一部分是在部署後提供對應用程式的輕鬆可見性。 除了執行階段基礎設施之外，請務必包括可觀察性和監控的設定。 在大多數情況下，需要在基礎設施即代碼（IaC）層面進行設定（例如，代理程式部署、儀表化），而在其他情況下，它可能是另一類型的設定即代碼成品（例如，用於監視 Azure Application Insights 的儀表板）。 最後，請務必包含使用您選擇的工具進行分散式追蹤、記錄和可觀察性的程式碼範例程式碼。 |
| 編碼環境設定 | 包括用於編碼語法檢查工具、程式碼格式化工具、編輯器和整合開發環境的配置文件。 包含安裝腳本以及工作區或工作站虛擬化文件，例如 devcontainer.json、 devbox.yaml、以開發人員為中心的 Dockerfile、Docker Compose 檔案或 Vagrantfiles。 |
| 測試組態 | 使用您慣用的服務 （ 例如 Microsoft Playwright Testing for UI 或 Azure 應用程式測試） 提供單元和更深入測試的組態檔。 |
| 協作工具設定 | 如果您的問題管理和原始檔控制管理系統支援任務/問題/PR 範本作為程式碼，請也包含這些範本。 如果需要更多設定，您可以選擇性地提供工作流程/管線，以使用可用的 CLI 或 API 來更新您的系統。 這還允許您設置其他協作工具，例如 Microsoft Teams 或 Slack。 |