設計開發人員自助基礎
一旦您對工程系統的目標有很好的瞭解，您就可以建立更複雜的開發人員自助體驗。 開發人員自助體驗是以概念、模式和元件為基礎所建置。
雖然您目前在組織中可能不需要這裡所述的一切，但如果您建置自定義或評估相關產品，您應該記住這些概念。 您的開發人員自助體驗模型可以由本土、現成和開放原始碼產品的組合所組成。 如 Backstage.io 之類的產品或開放原始碼入口網站工具組，可能會針對下列模型的某些元素使用不同的詞彙，但模型仍可協助引導您。
自動化工作流程、匯總數據、開始簡單，並逐步展開
您的目標是透過受控制、控管的工作執行和布建，以及集中式可見度，啟用具有護欄的自助功能。 最值得關注的領域是那些既乏味，要麼是開發人員因為複雜度或許可權而無法自行執行的工作。 最後一個部分對於讓您遵循最低許可權原則很重要，而不需要透過手動服務台程式強制開發人員。
雖然您可以選擇擴充 DevOps 套件以符合這些需求，但您可能需要隨著時間支援多個 應用程式平臺 ，以及支援它們的特定工具和程式也需要變更。 核心問題是您的標準是移動的目標。 正如一位平臺工程從業者所述：
困難涉及標準化... 和處理'放棄軟體'... 由於自動化程式的潛在中斷，以及識別必要變更的耗時工作，通常無法達到標準化。 - Martin，DevOps 工程師，大型物流公司
快速切換到新的或更新的標準通常不可行，而放棄現有的程式會造成風險。 您的組織可能已經使用多個 DevOps 套件，或依案例的不同個別工具和開發人員服務組合。 即使有中央小組和標準解決方案，因為您的自助需求增加，變化是不可避免的。 因此，您會想要啟用受控制的實驗，其中指定的小組可能會嘗試新技術、部署策略等等，然後是刻意採用和累加推出。
一般而言，自助體驗分為兩個主要類別：自動化和數據匯總。
雖然數據匯總會建立良好的用戶體驗，但自動化更重要：
自動化是關鍵，每個人都會喜歡。 [數據] 匯總是次要的。 – Peter，平臺工程主管，跨國科技公司
在平臺工程 旅程中，您已找出自動化可能解決的問題。 除了減少認知負載和開發人員的辛勞之外，自動化也可以協助確保應用程式連線到作業、安全性和其他角色的最佳工具和服務，以執行其工作。
不過，如果您使用多個系統來驅動自動化，則某些層級的數據匯總有助於追蹤自動化要求和相關聯的結果。 您可以從連結至外部系統，以符合其他需求或鑽研詳細數據開始。 數據匯總和可見度對於稽核、治理和減少浪費也很重要（例如：未使用的環境）。
您可以使用系統整合來自動化基礎結構布建之類的專案，但您也可以觸發並協助手動工作流程程式，讓開發人員自動化。 這在平臺的早期階段、您帶入生態系統的新產品，或在您尚未或無法自動使用系統的區域（例如軟體授權指派）中很有用。 使用正確的設計，您可以從Power Automate 之類的手動程序開始，讓您在一段時間內切換至完全自動化流程。 因此，從一開始就設計自動化。
藉由重複使用現有的投資，例如您的工程系統或內部入口網站，然後建立CLIS、基本網頁，甚至是 Power Pages、 Power BI或 Microsoft網狀 架構儀錶板，然後視需要擴充而開始。 擁有UX接著使用的一致 API 可協助您隨著需求和喜好設定變更，一段時間支援多個介面。
開發人員自助平臺元件：API、圖形、協調器、提供者和元數據
請考慮開發人員自助的基礎：
如下圖所示，下列元件構成開發人員自助基礎概念的核心：
| 元件 | 描述 |
|---|---|
| 開發人員平臺 API | 這是您用戶體驗的單一連絡點。 它實際上是系統與其他系統的合約。 |
| 開發人員平台圖表 | 受控且安全的數據圖形，可讓您探索、關聯及使用不同類型的實體和範本。 實體是一個物件，可啟用來自多個來源的數據匯總，而範本則驅動啟用自動化的用戶輸入。 |
| 開發人員平台協調器 | 一項功能，可路由和追蹤範本型要求，以在系統中或透過手動程式執行動作。 這些要求會路由傳送至一組開發人員平臺提供者，這些提供者可以整合到任意數目的不同工作流程系統或其他服務。 |
| 開發人員平臺提供者 | 一元件，封裝與下游系統整合所需的邏輯，以支持實體和/或履行範本型動作要求的 CRUD 作業。 每個提供者都可以支援自己的特定範本類型，併發出唯一或常見的實體類型。 |
| 使用者配置檔和小組元數據 | 能夠保存一組系結至概念小組的個人相關信息，以便分組及存取開發人員平臺 API。 使用者與身分識別提供者帳戶緊密關聯（例如，Microsoft Entra ID 登入），但兩者與小組都可以系結至任意數目的相關下游系統表示法。 這項資訊存放區的其中一個實作是重複使用開發人員平台圖表。 開發人員自助基礎可以為使用者和小組建立通用實體類型，並將該資訊保存在圖表中。 不過，為了清楚起見，我們將將此存放區分開。 |
這些基礎元件可讓您在一段時間內使用和交換不同的建置組塊。
我是否必須建置這一切才能開始使用？
否。 首先，這是一種概念模型，可協助您思考完成之後，應該能夠執行這類基礎的功能。 其次，由於開發人員平臺 API 成為您的主要介面，這裡的實作細節就不那麼重要了。 您的初始實作可能會從程序代碼中的介面和類別開始，以取得其他產品中所述或混合的不同層。 您也可以省略層面，因為客戶開發會告訴您這隻是較低的優先順序。 從您擁有和成長的內容開始。
開發人員平臺 API
您應該定義開發人員平臺 API 作為系統合約。 不同的使用者介面會使用 API 來啟用資料存取或磁碟驅動器布建和其他動作。
此 API 可藉由將其他系統中原始基礎 API 的存取限制為更特定且受控制的數據和作業，作為重要的驗證和安全性層。 API 可讓您存取自己的使用者配置檔表示法、平臺內的用戶高層級角色（小組成員、系統管理員等），以及主要身分識別提供者系統標識碼。 如需詳細資訊，請參閱 使用者和小組。
開發人員平臺提供者
假設內部開發人員平臺的廣度，請建立或識別遵循可延伸提供者模型的系統，以將功能引入 API。 其概念是，自動化和數據匯總等重要功能是透過與已定義完善的介面的插入式元件互動來提供。 這種鬆散結合可協助您以累加方式連接所需的專案，並改善可維護性，因為您可以測試與基礎其餘部分無關的功能。
這也是啟用平臺可調整 內部來源 心態的重要方式。 一般而言，由於持續維護的挑戰，圍繞平臺工程的內部採購工作無法獲得牽引力。 其他小組可能願意提供功能，但不太可能願意維護及測試平臺核心內的內容。 相反地，任何集中式小組都有有限的容量來維護參與的程序代碼，甚至檢閱提取要求。 開發人員平臺提供者的概念可藉由允許獨立撰寫的程式代碼「插入」到開發人員自助基礎內的核心功能，來緩解這種緊張。 雖然您應該仔細管理您使用的提供者、檢閱任何提供者程序代碼，以及限制指定提供者可在開發人員平臺中存取的介面區，但插入式方法可協助您透過調整整個組織更廣泛部分的工作來完成更多工作。
重要的開發人員平臺提供者概念
實體
實體的概念是您內部開發人員平臺中開發人員或其他系統需要追蹤、更新、呈現或採取行動的專案。 實體可以彼此建立關聯性，當結合在一起時，組成一個 圖形 ，以提供內部開發人員平臺片段的重要資訊。 開發人員平臺提供者接著可以輸出實體以啟用核心功能，包括：
- 呈現外部布建的資源/環境或可用 API 以供探索及使用
- 公開相依性分析、影響分析、探索等關聯性。
- 探索和共同作業的呈現維護者/擁有權資訊
- 顯示更多數據以用於用戶體驗
將這項功能封裝到定義完善的開發人員平臺提供者介面，可簡化整合和測試、啟用獨立部署，並允許主要內部開發人員平臺小組外的開發人員參與和管理提供者。 這在大型或部門組織中很重要，並非所有工具、服務或平臺都是集中管理，但更廣泛的組織仍想要共用功能。 所以，即使你一開始不走這條路，從長遠來看，這是一些思考的東西。
通用屬性
每個實體都應該有一組通用屬性，以允許Foundation管理它們。 要考慮的一些屬性包括：
- 唯一識別碼
- 名稱
- 原始提供者
- 選擇性關聯至：
- 擁有使用者
- 擁有團隊
- 其他實體
使用者和小組屬性很重要，原因有三個：角色型訪問控制 （RBAC）、探索和數據匯總（例如小組層級摘要）。 從一開始就在 RBAC 中建置對於安全性及隨著時間成長內部開發人員平台至關重要。 假設開發是一項團隊運動，探索與實體交談的人員將很快成為重複使用、支援和內部環境的關鍵。
通用和提供者特定實體
您也應該能夠建立一組常見的高階正規化實體，讓多個提供者可以輸出。 例如：
- 環境
- 資源
- API
- 存放庫
- 元件
- 工具
這些通常應該位於高階，就像您在 C4 模型 內容 或大部分高階 元件 圖表中一樣。 例如，針對環境，您不需要包含內部基礎結構地形的詳細數據：您只需要足夠的資訊，即可列出和關聯相同 UX 中多個提供者的不同概念環境。 實體可以指向系統外部較低的詳細層級，而不是嘗試取用所有專案。 這些提供探索的起點是啟用一段時間的數據匯總的核心。
其他則是特定使用案例或提供者特有的，因此您應該思考一段時間后如何容納一組日益成長的實體類型。
範本
此內容中範本的概念與實體的概念不同，因為實體的目的是要推動動作。 範例案例包括基礎結構布建、建立存放庫和其他長時間執行的進程。 這些範本也應該透過可延伸的開發人員平臺提供者取得，而且應該支援與實體相同的通用屬性，包括實體關聯。
不過，他們也可以定義執行動作所需的輸入，無論是系統或使用者指定的。 這些範圍可以從將資源命名為選擇性新增專案等任何專案。
樣本範例包括：
- 基礎結構即程序代碼 （IaC） 範本
- 應用程式範本 （從右開始）或範本存放庫
- 建置管線/工作流程範本
- 部署管線/工作流程範本
- 參數化腳本
- 參數化 Power Automate 流程（例如：HTTP 要求觸發的雲端流程）
- 電子郵件範本
和實體一樣，範本可以包含提供者的特定屬性。
每個範本可能有不同的表示法，對提供者而言是唯一的。 這些範圍可能從 Terraform 或 ARM 範本到 Helm 圖表、參數化的 GitHub Actions 工作流程或 Azure Pipelines、簡單腳本或自定義格式。
實際的基礎範本詳細數據不一定需要集中儲存。 它們可能存在於不同的存放庫、登錄或類別目錄中。 例如，您可以使用 GitHub 範本存放庫作為應用程式範本，而您的 IaC 範本可能存在於受限制的目錄存放庫中，開發人員只能透過 Azure 部署環境之類的專案間接存取。 其他 IaC 範本可能會儲存在 OCI 成品登錄中，例如 Helm 圖表。 在其他情況下，範本可能是參數化 HTTP 端點的參考。 開發人員平臺提供者應該提供有關每種範本類型的資訊，以便參考這些範本，以及公開用於用戶體驗的任何選項。 但是，範本本身可以儲存在您使用案例的最自然位置。
特定領域的平台工程師或專家撰寫範本，然後與開發小組共用範本以供重複使用。 透過系統集中使用這些範本，可讓開發人員自助，並建立護欄，協助強制執行組織標準或原則的合規性。 當我們在一點中討論開發人員平臺協調器時，會進一步瞭解這一點。
開發人員平台圖表
您可以將開發人員平臺圖形視為可讓您將多個提供者的實體和範本關聯至可搜尋圖表。 不過，實體的實際數據不一定需要直接保存在圖形特定資料庫中。 相反地，可以快取與提供者的互動，以及所需的元數據，使其全部配合在一起。
當與多個提供者可能參與的常見實體搭配使用時，圖表就很強大。 例如，API 清單可能來自 Azure API 中心等產品，但您可能也想要從您的持續部署系統自動在部署和環境中摘要。 一段時間后，您可以在不同的部署系統之間切換，甚至支援多個部署系統。 只要每個部署系統都有開發人員平臺提供者，您仍然可以建立關聯。
接著，您從此圖表建置的每個用戶體驗，都可以利用一般 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 實例，並使用 Actions REST API 引發工作流程分派事件 來觸發工作流程執行。 每個工作流程都可以藉由將workflow_dispatch組態新增至工作流程 YAML 檔案，以支援一組輸入。 Azure DevOps 觸發程式 很類似，您也可以使用 Azure DevOps Pipeline API 來執行。 您可能會在其他產品中看到相同的功能。
這些工作流程或管線不需要位於應用程式原始程式碼存放庫中。 概念是利用這個事實來執行類似如下的事情：
- 平台工程師或 DevOps 小組成員可以在開發人員本身無法存取的一或多個中央存放庫中維護工作流程/管線，但開發人員平臺提供者已設定為使用。 這個相同的存放庫可以包含工作流程/管線所使用的腳本和 IaC 代碼段。
- 若要允許這些工作流程/管線與適當的下游系統互動，平臺工程小組的作業或其他成員可以在中央存放庫中新增所需的秘密。 如需如何執行這項操作的詳細資訊，請參閱 GitHub Actions 和 Azure DevOps 檔，或者您可以選擇使用 Azure 金鑰保存庫 之類的內容來集中處理秘密。
- 然後，這些工作流程/管線可以遵循模型，將任何產生的實體發佈為組建/部署成品（GitHub 檔、 Azure DevOps 檔）。
- 在執行期間，開發人員平臺提供者接著可以監看工作流程/管線的狀態，並在協調器中更新生命周期狀態，直到完成為止。 例如，您可以使用 Web 攔截搭配 GitHub Actions ，以及搭配 Azure Pipelines 的服務攔截來追蹤更新。
- 完成後，提供者就可以視需要取用已發佈的成品，以納入開發人員平台圖形中。
最後，您可以設定此開發人員平臺提供者，將一組範本輸出至開發人員平台圖形，以參考適當的存放庫和工作流程/管線，以及指定工作的輸入。
使用 CI/CD 系統的絕佳方式是，它們通常會設定為支援執行任意 CLIS，因此您不需要第一類、唯一的整合，才能完成所有作業。 您可以視需要新增那些經過一段時間。
此範例所描述的大部分內容都適用於其他類型的提供者如何運作。 也請務必注意，在此內容中使用 GitHub Actions 或 Azure Pipelines 並不需要您也將其用於實際的 CI/CD 管線。
其他範例
以下是可處理範本之其他類型的開發人員平臺提供者的一些範例。
| 範例 | 描述 |
|---|---|
| 原始檔控制作業 | 在某些情況下，您可能需要建立或更新存放庫、提交PR，或執行其他原始檔控制相關作業。 雖然一般異步工作流程引擎可以管理這類作業，但是能夠執行基本的 Git 作業，而不需要一個作業就很有用。 |
| 基礎結構布建者 | 雖然 GitHub Actions 和 Azure Pipelines 適用於管理基礎結構布建，但您也可以選擇更直接的整合。 專用提供者可以簡化設定並避免額外負荷。 Azure 部署環境或 Terraform Cloud 等服務更直接著重於啟用以 IaC 範本為基礎的布建，並安全地進行。 其他範例可能包括在共用叢集中建立應用程式的 Kubernetes 命名空間，或使用使用 Flux 或 Argo CD 做為特定提供者類型的 GitOps 工作流程使用 git。 更以應用程式為中心的模型，例如實驗 性Radius OSS孵化專案與自己的CLI，可能會隨著時間而有自己的開發人員平臺提供者。 關鍵是尋找並規劃擴充性，以便您進行調整。 |
| 應用程式 Scaffolding / seeding | 應用程式範本是平臺工程隨時間推移的重要部分。 您可以藉由提供專用的開發人員平臺提供者來支援您選擇的範本引擎，此提供者不僅設計成建構應用程式來源樹狀結構，還可以建立內容並將其推送至原始程式碼存放庫，並將產生的實體新增至圖形。 每個生態系統都有自己的應用程式 Scaffolding 喜好設定，無論是 Yeoman、cookiecutter 或 Azure 開發人員 CLI 之類的專案，因此這裡的提供者模型可讓您從相同的介面支援多個。 同樣地，這是關鍵所在擴充性。 |
| 手動程序 | 無論是自動產生PR以進行手動核准，還是非開發人員角色的手動工作流程步驟，都可以在開發人員平臺提供者中使用相同的範本型模型來回應。 您甚至可以隨著時間移至更自動化的步驟。 |
雖然您可能不需要所有這些提供者開始，但您可以透過開發人員平臺提供者之類的專案來了解擴充性如何協助您的自動化功能隨著時間成長。
使用者和小組
平臺工程本質上是多系統事務，因此規劃自助基礎應該如何處理將這些系統整合在一起的更具挑戰性的問題非常重要。以下是解決身分識別、使用者和小組共同挑戰的策略。
| 建議 | 描述 |
|---|---|
| 將開發人員平臺 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 開發人員中心 Project 等專案整合，其已有這些核心 RBAC 建構可用。
在小組或用戶層級建立與下游系統整合的模型
雖然某些開發人員和作業工具/服務會以原生方式整合和使用識別提供者概念，但許多人會將此概念抽象化為群組或使用者本身的表示法（即使是使用 SSO）。 除了啟用跨工具的存取之外，此實境也可能會對數據匯總造成問題。 具體來說，您可能會發現下游系統中的 API 會使用自己的識別碼，而不是識別提供者識別碼（例如：Entra ID 中的物件識別碼未直接使用）。 這會使篩選和關聯使用者或小組層級數據變得困難，除非您可以在不同的標識符之間對應。
解決小組和群組層級的差異
TaC 之類的模式可讓您儲存和存取每個系統小組或群組標識碼之間的關聯性，以便您可以在它們之間對應。 為了回顧，安全且可稽核的 Git 存放庫會成為小組的來源，而 PR 會提供受控的使用者介面來進行更新。 CI/CD 系統接著可以更新下游系統，並保存其用來執行此動作之小組的相關標識符關聯性。
例如，這可讓下列關聯性儲存在 API 呼叫中：
如果您想要在存放庫中使用檔案以外的數據源，您的小組可以使用開發人員平臺協調器來套用這個相同的一般概念，以完成相同的工作。 在此模型中，小組數據來源的開發人員平臺提供者可以觸發所有其他提供者視需要接收並採取動作的小組更新事件。
解決使用者標識碼挑戰
數據存取和匯總的另一個相關挑戰是使用者標識碼差異。 如同在小組案例中，如果您使用系統對系統整合來查詢使用者的相關數據，則無法假設識別提供者原生標識碼 （例如，Entra ID 的物件標識符） 支援指定的 API。 在這裡，再次儲存透過開發人員平臺 API 存取資料的使用者識別碼對應可協助。 例如，請考慮 GitHub：
針對每個系統，如果您可以透過沒有使用者令牌的API來查閱另一個系統的使用者識別元，則指定的開發人員平臺提供者可以即時產生此對應。 在某些情況下，這可能會變得很複雜，因為您可能需要大量執行這項作業，並快取結果以供參考以維護效能。
使用多個使用者令牌回復
如果提供者需要存取用戶層級數據，而不需要執行可運作的使用者標識元翻譯，開發人員平臺 API 可以設定為管理多個使用者令牌。 例如：
- 開發人員平臺 API 可以支援提供者特定使用者令牌的快取，以便與下游系統搭配使用。
- 如果可用，與 API 所觸發之指定提供者的任何互動，都會包含在提供者的使用者令牌中。
- 若要處理沒有使用者令牌可供使用的情況，提供者會觸發 OAuth 流程以取得一個令牌。
- 首先，開發人員平臺 API 會使用傳遞至提供者的重新導向 URI，傳回 OAuth 流程的驗證 URI。 傳入的 URI 會包含 nonce /一次性使用程式代碼。
- 接著，API 會傳回 URI 的「未驗證」回應。
- 然後，任何 UX 都可以使用此 URI 在瀏覽器中驅動適當的驗證流程。
- 重新導向發生之後，開發人員平臺會收到所需的使用者令牌，並快取以供日後參考，以及使用者標識碼。
- 然後，用戶端可以重試 API 呼叫，然後會成功。
此概念概述處理複雜驗證的方法，因為您可以盡可能重複使用標識碼，而且不需要為每個下游系統維護個別的重新導向 URI。
使用內容感知深層連結至工具和報告系統
到目前為止，我們一直在討論問題空間的自動化層面。 這一點可能很長，因為您的UI可以在自動化期間傳回的實體中使用值，為小組建立其他系統的深層連結。
即使與自動化無關，開發人員平臺提供者也可以發出任何類型的實體需求。 不過，您通常不想將整個內部開發人員平臺的所有詳細數據帶入開發人員平台圖表。 Grafana、Prometheus、DataDog 或 SonarQube 等產品中的程式代碼智慧解決方案中的儀錶板，以及 GitHub 和 Azure DevOps 等 DevOps 套件中的原生功能全都非常有能力。 相反地，最好的方法是建立這些其他系統的深層連結。 您的實體可以提供足夠的資訊來建立連結，而不需要直接包含記錄內容等詳細資訊。
如果您想要跨工具匯總和摘要數據，或需要驅動自定義計量，報表解決方案 Power BI 或 Microsoft Fabric 可以是下一個呼叫埠。 若要合併小組數據，您可以連線到 Foundation 的資料庫，或瀏覽開發人員平臺 API。 例如，如規劃和優先順序中所述，您可能會想要自定義儀錶板的一個位置測量內部開發人員平臺的成功。
選擇您建置的每個額外體驗
雖然它可以吸引重新建立現有功能，例如常見的入口網站，但請記住，您也需要維護它。 這是遵循產品思維很重要的領域。 儀錶板樣式介面很容易受孕和瞭解，但您的開發人員可能會在其他地方找到更多價值。
也就是說，這裡的模型可讓您使用開發人員平台圖形中的匯總數據來建立自定義用戶體驗。 實體應具有內建支援，以便與使用者或小組系結。 這可讓您的開發人員平臺 API 設定輸出範圍（以及使用索引編製和快取）。
不過，即使您需要建立自定義UX而非深層連結，將所有數據提取到您的開發人員平台圖表通常仍然不是最佳方法。 例如，假設您想要在UX中顯示已定義且受管理良好的首頁記錄。 使用相關實體中的資訊，協助您的UX直接從下游系統收集資訊。
若要開始，您可能需要使用系統對系統整合進行連線，但一旦實作使用者和小組中所述的其中一個模型，您可以視需要使用任何儲存的下游使用者/小組標識碼或使用者驗證令牌。
以下是一些要考慮的常見體驗範例：
| 範例 | 描述 |
|---|---|
| 發現與探索 | 正如一位平臺工程從業者所說，“減緩專案的速度是溝通，而不是開發人員技能。”-Daniel，財富 500 媒體公司，雲端工程師。 由於軟體是團隊運動專案，因此建立使用者介面來協助探索團隊，而他們擁有的實體通常是要處理的第一件事之一。 跨小組搜尋、探索和文件有助於提升重複使用，並協助共同作業內部來源或支援。 Teams 也受益於擁有一站式商店來尋找自己擁有的專案，包括環境、存放庫和其他資源，例如檔。 |
| 手動註冊環境或資源 | 雖然許多專案可以透過開發人員平臺協調器布建和追蹤，但您可能也想要註冊已經存在或尚未自動化的資源或環境。 從 Git 存放庫取得資訊的簡單提供者，並將資訊新增至資源/環境管理，在這裡很有用。 如果您已經有軟體目錄，這也會成為將它整合到模型中的方式。 |
| API 目錄 | 開發人員應該使用的追蹤 API 可能會有很長的路要走。 如果您還沒有專案，您甚至可以從一系列代表 API 的檔案、其狀態的簡單 Git 存放庫開始，使用 PR 來管理您的核准工作流程。 這些可以新增至您的開發人員平台圖形，以便顯示或與其他實體建立關聯。 如需更強固的功能，您可以整合Microsoft API 中心或其他產品等專案。 |
| 授權合規性 | 在某些情況下，您可能也想要提供軟體授權合規性和授權耗用量的可見度。 開發人員平臺也可以新增取用授權所需的自動化，但即使授權是手動指派的（例如，透過 Git 存放庫中的 PR 程式），開發人員也能瞭解他們擁有的內容（以及系統管理員在所有專案上都能看到的能力）。 |
| Kubernetes 的應用程式中心檢視 | 當您使用共用 Kubernetes 叢集時，開發人員很難透過叢集管理員 UX 尋找及瞭解其應用程式的狀態。 不同的組織可能會選擇以不同的方式處理這個問題，但使用命名空間來代表應用程式是其中一個已知的方式。 您可以從該處使用實體來建立叢集中應用程式命名空間與小組之間的關聯，並針對應用程式建立更具開發人員焦點的狀態檢視，並提供其他工具或 Web UI 的深層連結。 |
用戶體驗
您組織中的不同角色具有工具或服務，代表日常工作的重心。 這些系統的提取使得這些重力中心以外的新用戶體驗難以獲得牽引力。 在完美的世界中，開發人員、作業和其他角色可以繼續在對他們有意義的環境中工作，通常是他們已經在使用的環境。
考慮到這一點，當您進行平臺工程旅程時，規劃多個使用者介面是個好主意。 這也可以提供一個機會，以在需要時開始簡單、證明價值，並成長為更複雜的介面。
整合您擁有的內容
如果您已閱讀過套用軟體工程系統和精簡應用程式平臺文章，您可能會識別出您想要繼續使用的系統。 在任一情況下，評估您是否可以在從頭開始建置新體驗之前，先增強並擴充您擁有的內容。 （問自己，人們會對另一個新的用戶體驗做出更好的反應，還是他們現在擁有的改良版本嗎？
您想要繼續使用的一些工具、公用程式或 Web 應用程式是自定義的，這些是增強功能的良好候選專案。 但別忘了注意您最愛的工具和服務是否有您可以使用的擴充性模型。 從那裡開始，你會得到很多好處。 這可以消除維護和安全性問題，並讓您專注於您嘗試解決的問題
例如，您可能能夠擴充您已使用的下列介面：
每個角色的起點可能都比您從頭開始設定的角色提供更好的起點，因為它們是現有的重力中心。 以一般開發人員平臺 API 作為基準可讓您交換一些專案、實驗和隨著時間變更。
請考慮使用 Web 編輯器延伸模組來建立開發人員入口網站
如果您要尋找適用於開發人員的網頁式體驗，請記住，最近的趨勢是以 Web 為基礎的編輯器和 IDE 版本。 許多人，就像使用 VS Code 一樣，都有延伸模組支援。 使用 VS Code 時，您為這些 Web 體驗建置的任何專案，然後轉譯在本機以取得雙重好處。
除了 GitHub Codespaces 等服務之外，vscode.dev 是不含計算的免費 VS Code 編輯器網頁版本，但包含特定類型的擴充功能支援，包括針對自定義 UI 使用 WebView 的擴充功能。
即使您的開發人員未使用 VS Code 本身，UX 模式也是眾所周知的，而且可以在其他開發人員工具中找到。 除了工具本身之外，使用 vscode.dev 可以提供方便且熟悉的網頁式基礎，以取得開發人員體驗。
這些可以做為開發人員焦點入口網站，以熟悉的表單，也可以轉譯為本機用途。
ChatOps
通常忽略的另一個機會是實作 ChatOps 介面。 由於 ChatGPT 和 GitHub Copilot 等 AI 產品增加，動作命令或斜線命令可能會提供有用的方法來觸發自動化工作流程、檢查狀態等等。 假設大部分的應用程式 CI/CD 平臺都對像是 Microsoft Teams、Slack 或 Discord 等系統提供現成支援，這可能是每天使用與另一個使用者介面開發人員和相關作業角色整合的自然方式。 此外，所有這些產品都有擴充性模型。
投資新的開發人員入口網站
假設您沒有想要作為基底的現有入口網站或介面，您可能會決定建置新的開發人員入口網站。 將此視為目的地，而不是起點。 如果您還沒有開發小組與您合作，請開始此工作就是這麼做的時間。 每個組織都不同，因此對於這種體驗中應有的內容，沒有任何一個適合的答案。 因此，對於預先封裝的產品，您目前無法啟動並使用現成的預包裝產品。
針對自定義建置的自我裝載選項，一般入口網站架構並不新，而您的開發小組可能已經使用您可以點選的選項。 如果您嘗試在使用者面前取得某些專案以取得早期意見反應，您甚至可以從與低程式代碼 Power Pages 一樣簡單的項目開始，以聯機到常見的開發人員平臺 API。
較新的開發人員入口網站工作更有意見。 例如， Backstage.io 是一個自定義開發人員入口網站工具組，最初是專為符合 Spotify 的需求而建置的。 它包含 CLI，可協助啟動來源樹狀結構，就像 create-react-app 對React.js所做的一樣。
身為入口網站工具組，需要工作才能啟動，且自定義需要 TypeScript、Node.js和 React 的知識。 然而，它最大的事情是，作為工具組，你可以改變幾乎任何東西。 它也有自己的軟體類別目錄和範本化機制，但其使用並非必要，而且具有定義完善的方式，可引進稱為外掛程式的新 1st 和 3rd 合作物件程式代碼。