設計開發人員自助服務基礎

一旦您充分了解 工程系統的目標，您就可以建立更複雜的開發人員自助服務體驗。 開發人員自助服務體驗是建立在概念、模式和元件的基礎上。

雖然您目前可能不需要組織中此處描述的所有內容，但如果您建立自訂專案或評估相關產品，則應牢記這些概念。 您的開發人員自助服務體驗模型可以由自製、現成和開放原始碼產品的組合所組成。 產品或開放原始碼入口網站工具組 （例如 Backstage.io ） 可能會針對此處所述的模型某些元素使用不同的術語，但模型仍可協助您定位。

自動化工作流程、彙總資料、從簡單開始，逐步擴展

您的目標是透過受控、受控管的任務執行和佈建，以及集中式可見性，透過護欄啟用自助服務。 最值得關注的領域是那些乏味的領域，或者開發人員由於複雜性或權限而無法自己完成的事情。 最後一部分很重要，可以讓您遵循最小權限原則，而無需強迫開發人員通過手動服務台流程。

雖然您可以選擇擴充 DevOps 套件來滿足這些需求，但隨著時間的推移，您可能需要支援多個 應用程式平台 ，並且支援它們的特定工具和流程也可能需要變更。 核心問題是你的標準是不斷變動的目標。 正如一位平台工程從業者所說：

困難涉及標準化...... 以及處理“廢棄軟件”...... 由於自動化流程的潛在中斷以及識別必要變更的耗時任務，標準化通常無法實現。 - Martin，大型物流公司 DevOps 工程師

快速切換到新的或更新的標準通常是不可行的，放棄現有流程會產生風險。 您的組織可能已經在使用多個 DevOps 套件，或依案例使用個別工具和開發人員服務的不同組合。 即使有中央團隊和標準解決方案，隨著自助服務需求的增加，可變性也是不可避免的。 因此，您會想要允許受控實驗，讓指定的小組嘗試新技術、部署策略等等，然後刻意採用和累加推出。

一般來說，自助服務體驗分為兩個主要類別：自動化和數據聚合。

雖然資料聚合創造了良好的使用者體驗，但自動化更為重要：

自動化是關鍵，將受到每個人的喜愛。 [資料] 聚合是次要的。 – Peter，跨國科技公司平台工程主管

在您的 平台工程歷程中，您識別了自動化可能解決的問題。 除了減少認知負荷和開發人員的辛勤工作之外，自動化還可以幫助確保應用程式連接到營運、安全和其他角色的最佳工具和服務來完成其工作。

不過，如果您使用多個系統來驅動自動化，則某些層級的資料彙總有助於協助追蹤自動化要求及相關聯的結果。 您可以先連結至外部系統，以滿足其他需求，或深入了解詳細資料。 資料彙總和可見性對於稽核、治理和減少浪費 （例如，未使用的環境） 也很重要。

可以使用系統整合來自動化基礎設施佈建等操作，但您也可以觸發和促進開發人員看起來自動化的手動工作流程。 在平台的早期階段、當您將新產品引入生態系統時，或者在尚未或無法透過系統自動化的領域（例如，指派軟體授權），這會非常有用。 透過正確的設計，您可以從 Power Automate 等專案協助的手動程式開始，隨著時間的推移，您可以切換至完全自動化的流程。 因此，從一開始就設計自動化。

從簡單開始，重複使用現有投資，例如工程系統或內部入口網站，然後移至建立 CLI 應用程式、基本網頁，甚至 Power Pages、Power BI 或 Microsoft Fabric 儀錶板，並視需要進行擴充。 擁有 UX 隨後使用的一致 API 可以幫助您隨著需求和偏好的變化隨著時間的推移支援多個介面。

開發人員自助服務平台元件：API、圖形、協調器、提供者和中繼資料

考慮開發人員自助服務的基礎：

如圖所示，下列元件構成了開發人員自助服務基礎概念的核心：

元件	Description
開發者平台 API	您的使用者體驗單一聯絡點。 這實際上是系統與其他系統的合約。
開發者平台圖表	受管理且安全的資料圖表，可讓您探索、關聯及使用不同類型的實體和範本。 實體是啟用來自多個來源的資料彙總的物件，而範本則驅動使用者輸入以啟用自動化。
開發人員平台協調器	一種功能，可路由和追蹤範本型請求，以在系統中或透過手動程序執行動作。 這些要求會路由傳送至一組開發人員平台提供者之一，這些提供者可以整合至任意數目的不同工作流程系統或其他服務。
開發人員平台供應商	一組封裝邏輯的元件，需要與下游系統整合，以支援實體上的 CRUD 作業或履行範本型動作要求。 每個提供者都可以支援其特定的範本類型，並生成獨特或共通類型的實體。
使用者個人資料和團隊中繼資料	保存與概念團隊相關的一組個人資訊的功能，以便分組和存取開發人員平台 API。 使用者與身分識別提供者的帳戶關係緊密（例如 Microsoft Entra ID 登入），但使用者和小組都可以連結至任意數量的相關下游系統表示。 此資訊存放區的其中一個實作是重複使用開發人員平台圖形。 開發人員自助服務基礎可以為使用者和小組建立通用實體類型，並將該資訊保存在圖表中。 但是，為了清楚起見，我們將把這家商店分開。

這些基礎元件可讓您隨時間使用和交換不同的建置區塊。

我必須構建所有這些才能開始嗎？

否。 首先，這是一個概念模型，可以幫助您思考像這樣的基金會完成後應該能夠做什麼。 其次，鑑於開發人員平台 API 成為您的關鍵介面，因此實作細節在這裡不太重要。 您的初始實作可能會開始在程式碼中使用介面和類別，以用於描述的不同層，或混合在其他產品中。 您也可以省略某些方面，因為您的客戶開發告訴您這只是一個較低的優先級。 從你擁有的開始並成長。

開發者平台 API

您應該定義開發人員平台 API 來作為系統的合約。 不同的使用者介面會使用API來啟用資料存取或驅動佈建和其他動作。

此 API 可作為重要的身份驗證和安全層，將對其他系統中原始底層 API 的存取限制為更具體、受控的資料和操作。 API 可讓您存取其自己的使用者設定檔表示法、使用者在平台內的高階角色 （團隊成員、管理員等） ，以及主要身分識別提供者系統識別碼。 如需詳細資訊，請參閱 使用者和小組。

開發人員平台供應商

鑑於內部開發人員平台的廣度，您應該建立或識別遵循可延伸提供者模型的系統，以將功能引入 API。 這個想法是，自動化和數據聚合等關鍵功能是通過與具有明確定義的接口的可插拔組件交互來提供的。 這種鬆散耦合有助於您逐步整合所需的組件，並提高可維護性，因為您可以在不依賴基礎其他部分的情況下測試功能。

這也是為您的平台實現可擴展的 內部來源 心態的重要方法。 通常，由於持續維護的挑戰，圍繞平台工程的內部採購工作無法獲得關注。 其他團隊可能願意貢獻功能，但不太可能願意維護和測試平台核心內的某些內容。 相反地，任何集中式團隊在管理貢獻的程式碼或審核 pull requests 方面的能力都有限。 開發者平台提供者的概念讓獨立撰寫的程式碼能夠插入至開發者自助服務平台中的核心功能，從而紓解這一緊張局面。 雖然您應該仔細管理您使用的提供者、檢閱任何提供者程式碼，並限制指定提供者可以在開發人員平臺中存取的介面區域，但可插拔的方法可藉由在組織的更廣泛部分調整工作來協助您完成更多工作。

主要開發人員平台提供者概念

實體或單位

實體的概念是開發人員或內部開發人員平台中的其他系統需要追蹤、更新、呈現或採取行動的內容。 實體可以彼此之間有關係，這些關係組合在一起時，會形成一個 圖表 ，提供有關內部開發人員平台各個部分的關鍵資訊。 然後，開發人員平台提供者可以輸出實體以啟用核心功能，包括：

• 顯示外部佈建的資源/環境或可用的 API 以供探索和使用
• 揭示依賴分析、影響分析、探索等關係。
• 顯示維護者/所有權資訊以進行探索和協作
• 顯示更多資料以用於使用者體驗

將此功能封裝到定義完善的開發人員平台提供者介面中，可簡化整合和測試、啟用獨立部署，並允許主要內部開發人員平台團隊以外的開發人員貢獻和管理提供者。 這對於大型或部門組織非常重要，因為並非每個工具、服務或平台都集中管理，但更廣泛的組織仍然希望共享功能。 因此，即使您最初沒有走這條路，從長遠來看，這也是需要考慮的事情。

一般屬性

每個實體都應該有一組通用屬性，以允許基金會管理它們。 需要考慮的一些屬性包括：

• 唯一識別碼
• 名稱
• 原始提供者
• 選擇性的關聯至：
  • 持有者使用者
  • 負責團隊
  • 其他實體

使用者和小組屬性很重要，原因有三個：角色型存取控制 （RBAC）、探索和資料彙總 （例如小組層級摘要）。 從一開始就納入 RBAC 對於安全性至關重要，並隨著時間的推移發展內部開發人員平台。 鑑於開發是一項團隊合作，找出關於一個實體應該與誰交流，將很快對於再利用、支持和內部協作變得至關重要。

通用和供應商特有實體

您也應該能夠建立一組多個提供者可以輸出的通用高階正規化實體。 例如：

• Environments
• Resources
• 應用程式介面（API）
• 存放庫
• Components
• Tools

這些通常應該在高階層級，就像您在 C4 模型上下文或高階 元件圖中所看到的一樣。 例如，對於環境，您不需要包含內部基礎結構地形的詳細資料;您只需要足夠的資訊來列出和關聯來自同一使用者體驗中多個提供者的不同概念環境。 該實體能夠指向系統之外的更少細節層次，而不必試圖完全吸收所有信息。 這些提供探索的起點，對於隨時間推移啟用資料彙總至關重要。

其他則特定於特定使用案例或提供者，因此您應該考慮如何隨著時間的推移適應不斷增長的實體類型集。

範本

在這種情況下，模板的概念與實體的概念不同，因為它們旨在驅動操作。 範例案例包括基礎結構佈建、建立存放庫和其他長時間執行的程式。 這些範本也應該透過可延伸的開發人員平臺提供者提供，而且應該支援與實體相同的通用屬性，包括實體關聯。

不過，它們也可以定義執行動作所需的必要輸入，無論是系統或使用者指定。 這些內容可能包括資源命名或可選的新增項目。

範本範例包括：

• 基礎結構即程式碼 （IaC） 範本
• 應用程式範本 （開始右側） 或範本存放庫
• 建置管線/工作流程範本
• 部署管線/工作流程範本
• 參數化指令碼
• 參數化 Power Automate 流程 （例如，HTTP 要求觸發雲端流程）
• 電子郵件範本

與實體一樣，範本可以包含提供者特定的屬性。

每個範本可能都有提供者獨有的不同表示法。 這些範圍可能從 Terraform 或 ARM 範本到 Helm 圖表、參數化的 GitHub Actions 工作流程或 Azure Pipelines、簡單腳本或自定義格式。

實際的基礎範本詳細資料不一定需要集中儲存。 它們可能存在於不同的儲存庫、登錄或目錄中。 例如，您可以針對應用程式範本使用 GitHub 範本存放庫 ，而您的 IaC 範本可能存在於受限制的目錄存放庫中，開發人員只能透過 Azure 部署環境之類的內容間接存取。 其他 IaC 範本可能儲存在 OCI 構件登錄中，例如 Helm 圖表。 在其他情況下，範本可能是參數化 HTTP 端點的參考。 開發人員平臺提供者應該提供有關每種範本類型的足夠資訊，以便可以參考它們，以及公開用於使用者體驗的任何選項。 但是，範本本身可以存放在您的使用案例最自然的位置。

特定領域的平台工程師或專家編寫模板，然後與開發團隊共享以供重複使用。 透過系統集中使用這些範本，可讓開發人員自助服務，並建立護欄，以協助強制遵守組織標準或原則。 當我們稍後介紹開發人員平台協調器時，會詳細介紹這一點。

開發者平台圖表

您可以將開發人員平台圖表視為允許您將多個提供者的實體和模板關聯到可搜索圖表中的東西。 不過，實體的實際資料不一定需要直接保存在圖形特定的資料庫中。 相反，可以快取與提供者的互動以及所需的元數據，以使整體協同運作。

當與多個提供者可能貢獻的通用實體一起使用時，該圖表非常強大。 例如，API 清單可能來自 Azure API Center 等產品，但您可能也想要自動從持續部署系統饋送部署和環境。 隨著時間的推移，您可以在不同的部署系統之間切換，甚至支援多個部署系統。 只要每個部署系統都有開發人員平台提供者，您仍然應該能夠建立關聯。

然後，從此圖表建立的每個使用者體驗都可以利用通用 API 來支援探索、搜尋、治理等。 然後，開發人員平台協調器可以利用此相同的圖表，以便開發人員平台提供者執行的任何動作都會自動提供可供相同 API 使用的實體。

開發人員平台協調器

開發人員平台協調器可讓開發人員或系統建立要求，以使用範本執行動作。 它本身不會執行這些動作，而是與工作引擎、工作流程引擎或其他協調器協調來執行此動作。 這是您需要確保是自助服務基礎的一部分的關鍵部分之一。 它允許開發人員使用模板創建請求或在未經直接許可的情況下執行操作。 此外，與 CI 或 CD 的概念不同，這些動作不必與應用程式原始程式碼相關。

您可以使用 GitHub Actions、Azure Pipelines 或其他工作流程引擎作為協調器。 這是一個合理的起點，但您可能想要進行一些抽象，以允許不同類型的模板使用不同的底層引擎。 這可能很有用，原因如下：

• 首先，您可能希望能夠隨著時間的推移選擇不同的工作流程和任務執行引擎，而不必 閃切。 透過允許多個引擎，您可以隨時間遷移，或只是將新引擎移轉至新動作，而不會影響舊的動作。
• 您想要協助協調的某些程序最初可能需要手動步驟，即使您計劃稍後完全自動化它們。
• 其他動作可能會以開發小組以外的角色為目標，例如應付帳款或授權系統管理員。Power Automate 等低程式碼引擎通常適用於這些角色。
• 其他操作可能會透過簡單的 HTTP 請求來處理，不需要像 GitHub Actions 或 Azure Pipelines 這樣的服務，因為這樣做在擴展方面不必要或成本效益不高。

幸運的是，將開發人員平台提供商的概念擴展至涵蓋觸發和追蹤自動化步驟，可以提供所需的抽象層。 請考慮下圖：

這是一般概念：

• 範本可以選擇性地指定使用者可以輸入的一組輸入。 當開發人員觸發特定操作時，他們會選擇一個模板（即使沒有這樣描述）並輸入任何輸入。
• 範本相關輸入的引用會成為開發人員平台 API 中的請求。
• 提交要求之後，協調器內的要求路由和處理元件會開始追蹤要求的生命週期。 請求路由和處理元件，將請求中的範本路由至範本原始的開發人員平台提供者。
• 然後，開發人員平台提供者會執行適當的步驟來實作。
• （選用）開發人員平台提供者會在執行動作時更新要求狀態。
• 滿足要求之後，開發人員平台提供者可以傳回一組要在開發人員平台圖表中新增或更新的實體。 這些可以是提供者特定的實體或通用實體。

或者，為了支援更進階的互動，開發人員平台提供者可以直接呼叫開發人員平台 API，以取得更多實體作為輸入，甚至要求另一個相關動作。

選擇使用一般任務或工作流程引擎的開發人員平台提供者。 更具體地說，您需要一些東西來連結您所組合的這些內容，它們是 應用軟體工程系統的一部分。 需要投資的一種通用工作流程或任務執行引擎是 CI/CD 系統。

使用 GitHub Actions 或 Azure Pipelines 的範例

讓我們簡要看看 GitHub Actions 或 Azure Pipelines 作為開發人員平臺提供者的運作方式。

對於 GitHub Actions，實現此運作的關鍵是開發人員平台提供者可以連線到指定的 GitHub 實例，並使用 動作 REST API 來引發工作流程分派事件 以觸發工作流程執行。 每個工作流程都可以透過將 workflow_dispatch 組態新增至工作流程 YAML 檔案來支援一組輸入。 Azure DevOps 觸發程式 類似，您也可以使用 Azure DevOps 管線 API 進行執行。 您可能會在其他產品中看到相同的功能。

這些工作流程或管線不需要位於應用程式原始程式碼存放庫中。 這個概念是利用這個事實來做這樣的事情：

• 平台工程師或 DevOps 團隊成員可以在開發人員自己無法存取的一個或多個中央儲存庫中維護工作流程/管線，但已設定為被開發者平台提供商使用。 此相同的存放庫可以包含工作流程/管線使用的指令碼和 IaC 程式碼片段。
• 若要允許這些工作流程/管線與適當的下游系統互動，作業人員或平台工程團隊的其他成員可以在中央存放庫中新增所需的密碼。 如需如何執行此動作的詳細資訊，請參閱 GitHub Actions 和 Azure DevOps 檔， 或者您可以選擇使用 Azure 金鑰保存庫之類的專案集中秘密。
• 然後，這些工作流程/管線可以遵循模型，其中它們會將任何產生的實體發佈為建置/部署成品 （GitHub 檔、 Azure DevOps 檔） 。
• 在執行期間，開發人員平台提供者可以監看工作流程/管線的狀態，並更新協調器中的生命週期狀態，直到完成為止。 例如，您可以搭配 GitHub Actions 使用 Web 攔截，搭配 Azure Pipelines 使用服務攔截來追蹤更新。
• 完成後，提供者接著可以視需要取用已發佈的成品，以包含在開發人員平台圖表中。

最後，您可以設定此開發人員平台提供者，以將一組範本輸出到開發人員平台圖表中，這些範本會參考適當的存放庫和工作流程/管線，以及指定工作的輸入。

使用 CI/CD 系統的一大優點是，它們通常被設置為支持執行各種命令行介面（CLI），因此您不需要為您所做的每一件事情提供頂尖的獨特集成。 您可以視需要隨時間添加這些內容。

此範例中描述的大部分內容都適用於其他類型的提供者如何運作。 請同樣注意，使用 GitHub Actions 或 Azure Pipelines 並不意味著您必須將它們用於您的真正 CI/CD 管線。

其他範例

以下是可以處理範本的其他型別開發人員平台提供者的一些範例。

Example	Description
原始檔控制作業	在某些情況下，您可能需要建立或更新存放庫、提交 PR，或執行其他原始檔控制相關作業。 雖然一般非同步工作流程引擎可以管理這些類型的操作，但能夠在沒有非同步的情況下執行基本的 Git 操作可能會很有用。
基礎結構佈建者	雖然 GitHub Actions 和 Azure Pipelines 非常適合管理基礎結構布建，但您也可以選擇更直接的整合。 專用提供者可以簡化設定並避免開銷。 Azure 部署環境或 Terraform Cloud 等服務更直接地著重於啟用 IaC 範本型布建，而且安全可靠。 其他範例可能包括為共用叢集中的應用程式建立 Kubernetes 命名空間，或使用 Flux 或 Argo CD 作為特定類型的提供者，將 Git 與 GitOps 工作流程搭配使用。 隨著時間的推移，甚至更多以應用程式為中心的模型，例如具有自己的 CLI 的實驗性 Radius OSS 孵化專案，可能會擁有自己的開發人員平台提供者。 關鍵是尋找並規劃可擴展性，以便您可以適應。
應用腳手架/播種	應用程式範本是平台工程隨時間推移的重要組成部分。 您可以透過提供專用的開發人員平台提供者來支援您選擇的範本引擎，該提供者不僅旨在建立應用程式原始碼樹狀結構，還可以建立內容並將其推送到原始程式碼儲存庫，並將產生的實體新增至圖形中。 每個生態系統都有自己的應用程式模版偏好設定，無論是 Yeoman、cookiecutter 或類似 Azure Developer CLI 的工具，因此此供應模型可以讓您從相同的介面支援多個工具。 在這裡，可擴展性是關鍵。
手動流程	無論是自動產生手動核准的 PR，還是手動工作流程步驟，讓非開發人員角色使用 Power Platform 等方式回應，開發人員平台提供者都可以使用相同的範本型模型。 隨著時間的推移，您甚至可以轉向更自動化的步驟。

雖然您一開始不需要所有這些服務提供者，但您可以了解透過像是開發平台服務提供者的擴充性如何幫助您的自動化能力隨著時間增長。

使用者和團隊

平台工程本質上是多系統事務，因此規劃自助服務基礎應如何處理將這些系統整合在一起時更具挑戰性的問題非常重要。 以下是解決身分識別、使用者和團隊常見挑戰的策略。

Recommendation	Description
將開發人員平台 API 直接與您的身分提供者整合，以獲得最佳安全性。	為了保護開發人員平臺 API，我們建議直接與身分識別提供者整合，例如 Microsoft Entra ID，因為其健全的身分識別和 Entra ID 的 RBAC 功能。 直接使用身分識別提供者的原生 SDK 和 API （例如，透過 MSAL Entra ID） 而不是透過抽象概念，有許多優點。 您可以驅動端對端安全性，並在整個過程中依賴相同的 RBAC 模型，同時確保 持續評估條件式存取原則 （，而不是僅在登入時） 。
在下游系統中使用單一登入和身分識別提供者群組整合。	您的單一簽到（SSO）應用應該使用與您用於開發者平台 API 相同的身份提供者和租戶。 此外，請務必利用 SCIM 等協定的支援，以連線身分識別提供者群組 （如 AD 群組）。 將這些身分提供者群組連結至下游系統許可權並不總是自動的，但您至少可以手動將識別提供者群組與每個工具的分組概念建立關聯，而不需要之後手動管理成員資格。 例如，您可以結合 GitHub 的 企業受控使用者 （EMU） 支援，以及手動利用將 身分識別提供者群組繫結至 GitHub 小組的功能。 Azure DevOps 具有 類似的功能。

建立超越單一身分識別提供者群組的團隊概念

隨著您的平台工程旅程繼續進行，您可能會發現身分識別提供者群組非常適合管理成員資格，但多個群組確實需要聚集在一起，才能形成 RBAC 和資料彙總團隊的概念。

在平台工程的背景下，我們將團隊定義為一組不同角色、一起工作的人員。 對於資料彙總，多重角色團隊的概念對於在報告儀表板等地方促進資訊的發現與彙總至關重要。 另一方面，群組是一組使用者的通用身分識別提供者概念，設計理念是將多人指派到特定角色，而非相反。 因此，使用 RBAC，團隊可以透過不同的角色與多個身分識別提供者群組建立關聯。

團隊數據的來源可以來自幾個不同的地方。 例如，如果您使用 團隊即程式碼 （TAC） 模式，開發人員平台提供者可以監看存放庫中的檔案變更，並將其快取在使用者設定檔和團隊中繼資料存放區中。 或者，您可以直接與 Azure 開發人員中心專案 之類的專案整合，該專案已經有這些核心 RBAC 建構可供使用。

建立與團隊或使用者層級下游系統整合的模型

雖然某些開發人員和作業工具/服務會直接原生整合和使用身分識別提供者概念，但許多會將其抽象化為自己的群組或使用者表示法 （即使使用 SSO）。 除了實現跨工具訪問之外，這一現實還可能給數據聚合帶來問題。 具體而言，您可能會發現下游系統中的 API 會使用自己的識別碼，而不是身分識別提供者識別碼 （例如，不會直接使用 Entra ID 中的物件識別碼）。 這使得過濾和關聯使用者或團隊層級資料變得困難，除非您可以在不同的 ID 之間進行映射。

解決團隊和小組層級的差異

像 TaC 這樣的模式可以讓您儲存和存取每個系統的團隊或群組識別碼之間的關係，以便您可以在它們之間進行映射。 總而言之，安全、可稽核的 Git 存放庫會成為團隊的來源，而 PR 會提供受控的使用者介面來進行更新。 然後，CI/CD 系統可以更新下游系統，並保留其用來執行此動作的團隊的相關識別碼關係。

例如，這可讓您在 API 呼叫中儲存下列關聯性：

如果您想要使用小組存放庫中的檔案以外的資料來源，可以使用開發人員平台協調器套用相同的一般概念來完成相同的作業。 在此模型下，小組資料來源的開發人員平台提供者可以觸發小組更新事件，所有其他提供者都會接收並視需要採取行動。

解決使用者 ID 挑戰

資料存取和聚合的另一個相關挑戰是使用者 ID 差異。 就像在團隊案例中一樣，如果您使用系統對系統整合來查詢有關使用者的資料，則不能假設身分提供者原生 ID （例如，Entra ID 的物件 ID） 支援指定的 API。 同樣，儲存透過開發人員平台 API 存取資料的使用者 ID 的對應會有所幫助。 例如，考慮 GitHub：

對於每個系統，如果您可以透過 API 在沒有使用者權杖的情況下，在另一個系統中查詢使用者 ID，則指定的開發人員平台提供者可以即時產生此對應。 在某些情況下，這可能會變得複雜，因為您可能需要大量執行此操作並快取結果以供參考以維持效能。

依賴使用多個用戶代幣作為備用

如果提供者需要存取使用者層級資料，但無法進行有效的使用者 ID 翻譯，可以設定開發人員平台 API 來管理多個使用者權杖。 例如：

• 開發人員平台 API 可以支援提供者特定用戶權杖的緩存，以用於下游系統。
• API 觸發的與指定提供者的任何互動都會包含在提供者的使用者權杖中 （如果有的話）。
• 為了處理使用者權杖不可用的情況，提供者會啟動 OAuth 流程以取得權杖。
• 首先，開發人員平台 API 會傳回 OAuth 流程的驗證 URI，其中包含傳遞至提供者的重新導向 URI。 傳入的 URI 會包含隨機數/一次性使用代碼。
• 然後，API 會傳回帶有 URI 的 未經驗證的 回應。
• 然後，任何 UX 都可以使用此 URI 來驅動瀏覽器中的適當驗證流程。
• 重定向發生後，開發人員平台將收到所需的用戶令牌，並將其與用戶 ID 一起緩存以供將來參考。
• 然後，用戶端可以重試 API 呼叫，然後會成功。

此概念概述了一種處理複雜身份驗證的方法，因為您可以在可能的情況下重複使用 ID，並且不需要為每個下游系統維護單獨的重新導向 URI。

使用情境感知深層連結來連結至工具和報告系統

到目前為止，我們一直在討論問題空間的自動化方面。 僅此一項就可以發揮很大的作用，因為您的 UI 可以使用自動化期間傳回的實體中的值，為團隊建立指向其他系統的深層連結。

即便與自動化無關，開發平台提供商也能生成所需的任何類型實體。 不過，您通常不希望將整個內部開發人員平台的所有詳細資料帶入開發人員平台圖表。 Grafana、Prometheus、DataDog 等可觀測性解決方案中的儀表板，或 SonarQube 等產品中的程式碼智慧，以及 GitHub 和 Azure DevOps 等 DevOps 套件中的原生功能，都具備功能。 相反，最好的方法通常是創建與這些其他系統的深層連結。 您的實體可以提供足夠的資訊來建立連結，而無需直接包含日誌內容等詳細資訊。

如果您想要跨工具彙總和摘要資料，或需要驅動自訂計量，報告解決方案 Power BI 或 Microsoft Fabric 可能是您的下一個停靠港。 要合併團隊數據，您可以連接到基金會的數據庫或通過開發人員平台 API。 例如，如 規劃和優先順序中所述，您可能需要自訂儀表板的其中一個地方是衡量內部開發人員平台的成功程度。

對您建立的每項額外體驗都要有選擇性

雖然在通用入口網站之類的東西中重新創建現有功能可能很有吸引力，但請記住，您還需要維護它。 這是遵循產品思維很重要的領域。 儀表板樣式的介面易於構思和理解，但您的開發人員可能會在其他地方找到更多價值。

也就是說，這裡的模型允許您使用開發人員平台圖表中的彙總數據來創建自定義用戶體驗。 實體應該具有內建支援，以便與使用者或團隊連結。 這可讓您的開發平台 API 定義輸出範圍（以及使用索引和快取）。

然而，即使您需要建立自訂使用者體驗而不是深層連結，將所有資料提取到開發人員平台圖表中通常仍然不是最佳方法。 例如，假設您可能想要在已有明確定義且受管理的主體使用者體驗 (UX) 中顯示日誌。 使用相關實體中的資訊來協助您的使用者體驗直接從下游系統收集資訊。

若要開始，您可能需要使用系統對系統整合來連線，但一旦您實作 了使用者和團隊中所述的其中一個模型，您就可以視需要使用任何儲存的下游使用者/團隊 ID 或使用者驗證權杖。

以下是一些需要考慮的常見經驗範例：

Example	Description
發現與探索	正如一位平台工程從業人員所說：「減緩項目進度的是溝通，而不是開發人員的技能。」——丹尼爾，某《財富》500強媒體公司的雲端工程師。 由於軟體是一項團隊運動，因此建立使用者介面來協助發現團隊及其擁有的實體通常是首先要處理的事情之一。 跨團隊搜尋、探索和文件有助於促進重複使用，並協助協作以取得內部來源或支援。 團隊還可以從一站式商店中受益，以查找他們擁有的東西，包括環境、存儲庫和其他資源，如文檔。
手動註冊環境或資源	雖然許多專案可以透過開發人員平台協調器佈建和追蹤，但您可能也想要註冊已存在或尚未自動化的資源或環境。 從 git 儲存庫取得資訊並將資訊新增至資源/環境管理的簡單提供者在這裡可能很有用。 如果您已經有軟體目錄，這也成為將其整合到模型中的一種方式。
API 目錄	開發人員應使用的追蹤 API 將會帶來很大幫助。 如果您還沒有某些內容，您甚至可以從一個簡單的 Git 存儲庫開始，其中包含一系列代表 API 及其狀態的文件，使用 PR 來管理您的審批工作流程。 這些可以新增至您的開發人員平台圖表中，以便顯示它們或與其他實體相關聯。 如需更強大的功能，您可以整合 Microsoft 的 API Center 或其他產品等內容。
授權合規性	在某些情況下，您可能還想要提供軟體授權合規性和授權使用量的可見度。 開發人員平台也可以新增使用授權所需的自動化功能，但即使手動指派授權 （例如，透過 Git 存放庫中的 PR 程式），開發人員也能看到他們擁有的內容 （以及系統管理員查看所有內容的能力）。
以應用程式為中心的 Kubernetes 檢視	當您使用共用 Kubernetes 叢集時，開發人員可能很難透過叢集管理使用者體驗來尋找和了解其應用程式的狀態。 不同的組織可能會選擇以不同的方式處理此問題，但使用命名空間來表示應用程式是一種眾所周知的方法。 從那裡，您可以使用實體在叢集中的應用程式命名空間與團隊之間建立關聯，並建立更以開發人員為中心的應用程式狀態檢視，並提供其他工具或 Web UI 的深層連結。

使用者體驗

組織中的不同角色具有代表其日常工作重心的工具或服務。 這些系統的吸引力可能會使這些主要中心之外的新用戶體驗難以取得發展。 在完美的世界中，開發人員、營運和其他角色可以繼續在對他們有意義的環境中工作，通常是他們已經在使用的環境。

考慮到這一點，在平台工程旅程中規劃多個使用者介面是個好主意。 這也可以提供一個機會，從簡單開始，證明價值，並在需要時發展到更複雜的介面。

整合您所擁有的

如果您已閱讀應用 軟體工程系統 和 精簡應用程式平台 文章，您可能會識別出想要繼續使用的系統。 無論哪種情況，在開始從頭開始建置新體驗之前，請先評估您是否可以增強和擴充現有體驗。 （問問自己，人們會對另一種新的用戶體驗或他們現在擁有的東西的改進版本做出更好的反應嗎？

您想要繼續使用的一些工具、實用程式或 Web 應用程式將是自訂的，這些都是增強的良好候選者。 但不要忘記注意您最喜歡的工具和服務是否有您可以使用的擴展性模型。 從那裡開始你會得到很多好處。 這可以消除維護和安全難題，讓您專注於要解決的問題

例如，您可以延伸已使用的下列表面：

• 編輯器 和 IDE
• 您的 DevOps 套件
• CLI 的可擴展性也越來越強
• 低程式碼/無程式碼環境，例如 Power Pages

每個角色都可能比您從頭開始設定的角色提供更好的起點，因為它們是現有的重心。 使用通用的開發人員平台 API 作為基準，可讓您隨時間更換、實驗和變更。

考慮使用網頁編輯器擴充功能來建立開發人員入口網站

如果您正在為開發人員尋找基於 Web 的體驗，請記住，最近的趨勢是基於 Web 的編輯器和 IDE 版本。 許多 （例如使用 VS Code 的應用程式） 都有延伸模組支援。 使用 VS Code，您為這些 Web 體驗建置的任何內容都會在本機轉譯，以獲得雙重好處。

除了 GitHub Codespaces 等服務之外， vscode.dev 是 VS Code 編輯器的免費 Web 版本，沒有計算，但包含 對特定類型延伸模組 的支援，包括使用 Web 檢視 進行自訂 UI 的延伸模組。

即使您的開發人員不使用 VS Code 本身，UX 模式也是眾所周知的，並且可以在其他開發人員工具中找到。 除了工具本身之外，使用 vscode.dev 還可以為開發人員體驗提供方便且熟悉的基於 Web 的基礎。

這些可以以熟悉的形式充當以開發人員為中心的門戶，也可以轉換為本地使用。

聊天運營

另一個經常被忽視的機會是實施 ChatOps 介面。 鑑於 ChatGPT 和 GitHub Copilot 等人工智慧產品的興起導致基於聊天的介面的增加， 操作命令 或 斜線命令 可以提供一種有用的方法來觸發自動化工作流程、檢查狀態等。 鑑於大多數應用程式 CI/CD 平台都對 Microsoft Teams、 Slack 或 Discord 等系統具有開箱即用的支持，這可能是與開發人員和相關操作角色每天使用的其他使用者介面整合的自然方式。 此外，所有這些產品都有可擴展性模型。

投資新的開發人員入口網站

假設您沒有想要用作基礎的現有入口網站或介面，您可能會決定建置新的開發人員入口網站。 將其視為目的地而不是起點。 如果您還沒有開發團隊與您合作，那麼現在就是開始這項工作的最佳時機。 每個組織都是不同的，因此對於這種體驗中應該包含的內容，沒有一刀切的答案。 因此，目前尚無預設方案讓您可以立即啟動並原封不動地用於類似的預包裝產品。

對於自訂的自我裝載選項，一般入口網站架構並不新鮮，您的開發小組可能已經在使用您可以利用的架構。 如果您嘗試在使用者面前提供某些內容以取得早期意見反應，您甚至可以從低程式碼 Power Pages 等簡單專案開始，以連線到常見的開發人員平台 API。

最近的開發者門戶工作更加固執己見。 例如， Backstage.io 是一個自訂的開發者入口網站工具包，最初是為了滿足 Spotify 的需求而建立的。 它包括一個 CLI 來幫助初始化您的程式碼樹，就像 create-react-app 對 React.js 所做的一樣。

作為一個門戶工具包，它需要花一些功夫來設置，自訂則需要具備 TypeScript、Node.js 和 React 的知識。 然而，它的偉大之處在於，作為一個工具包，您幾乎可以更改任何內容。 它確實也有自己的軟體目錄和模板機制，但不需要使用它們，並且這是一種定義明確的方式來引入稱為插件的新程式碼。

相關內容

• Microsoft Power Pages
• Backstage.io
• 應用軟體工程系統