设计开发人员自助服务基础

对 工程系统的目标有了很好的了解后，就可以开始创建更复杂的开发人员自助服务体验。 在本部分中，我们将介绍一个概念体系结构，用于生成或评估为创建产品创建灵活基础的产品。 我们将这些概念、模式和组件统称为开发人员自助服务基础。

虽然目前组织可能不需要此处所述的所有内容，但在构建自定义内容或评估相关产品时，应牢记这些概念。 在你的世界中，此模型可以由本地、现成和开源产品的组合组成。 产品或开源门户工具包（如 Backstage.io ）可能会对本部分所述的模型的某些元素使用不同的术语，但模型仍可以帮助你确定方向。

Goals和注意事项

你在此领域工作的关键目标应该是通过受控、受管理的任务执行和预配以及集中可见性，通过护栏启用自助服务。 通常最有价值关注的领域是那些繁琐或开发人员由于复杂性或权限而无法自己做的事情。 最后一部分非常重要，可让你遵循最低特权原则，而无需强制开发人员完成手动服务台流程。

虽然可以选择扩展 DevOps 套件来满足这些需求，但随着时间的推移，你可能需要支持多个 应用程序平台 ，并且支持它们的特定工具和流程也需要更改。 核心问题是你的标准是一个移动的目标。 正如一位平台工程从业者所指出的：

困难涉及标准化... 和处理“放弃器”... 由于自动化流程的潜在中断和识别必要更改的耗时任务，通常无法实现标准化。 - Martin，DevOps 工程师，大型物流公司

正如此引文所强调的，快速切换到新的或更新的标准通常不可行，而放弃现有流程会产生风险。 你的组织可能已经使用多个 DevOps 套件，或者各个工具和开发人员服务的不同组合（按方案）。 即使有了中心团队和标准解决方案，随着自助服务需求的增长，可变性也是不可避免的。 因此，你需要启用受控试验，其中指定团队可能会尝试新技术、部署策略等，然后是有意采用和增量推出。

自助服务体验通常分为两个主要类别：

• 自动化
• 数据聚合

虽然数据聚合可以创造良好的用户体验，但正如一位平台工程从业者所说：

自动化是关键，将受到所有人的喜爱。 [数据] 聚合是次要的。 – Peter，跨国科技公司平台工程主管

出于此原因，你绘制的平台工程 旅程 很可能发现了一些可通过自动化解决的问题。 除了减少认知负载和开发人员的辛勤工作外，自动化还有助于确保应用程序连接到最佳工具和服务中，以便运营、安全和其他角色执行其工作。

但是，如果使用多个系统来推动自动化，则某种级别的数据聚合有助于跟踪自动请求和相关结果。 通常可以从链接到外部系统开始，以满足其他需求或深入了解详细信息。 数据聚合和可见性对于审核、治理和减少浪费也很重要， (示例：未使用的环境) 。

自动化基础结构预配等操作可以使用系统集成来完成，但你也可以触发和简化对开发人员看起来自动化的手动工作流过程。 这在平台的早期阶段非常有用，对于要引入生态系统的新产品，或者在尚未或不能使用系统 (例如软件许可证分配) 的区域。 通过正确的设计，你可以从一个手动流程开始，该流程由 Power Automate 等操作辅助，随着时间推移切换到完全自动化的流。 因此，从一开始就设计自动化。

鉴于产品思维模式以及最 薄的可行平台 (TVP) (平台) 的 MVP 的想法，应从重用现有投资（如工程系统或内部门户）开始，然后创建 CLI、基本网页，甚至 Power Pages、 Power BI 或 Microsoft Fabric 仪表板，并根据需要进行扩展。 考虑到这一点，拥有一个 UX 随后使用的一致 API 有助于随着需求和首选项的变化而随时间推移支持多个接口。

概念概述

请考虑下图：

如图所示，以下组件构成开发人员自助服务基础概念的核心：

组件	描述
开发人员平台 API	这是用户体验的单一联系点。 它实际上是系统与其他系统的协定。
开发人员平台图	一种托管且安全的数据图，可用于发现、关联和使用不同类型的实体和模板。 实体是一个对象，它支持来自多个源的数据聚合，而模板驱动支持自动化的用户输入。
开发人员平台业务流程协调程序	一种功能，用于路由和跟踪基于模板的请求，以在系统中或通过手动过程执行操作。 这些请求路由到一组开发人员平台提供程序之一，这些提供程序可以集成到任意数量的不同工作流系统或其他服务。
开发人员平台提供程序	封装与下游系统集成所需的逻辑的一组组件，以支持对实体执行 CRUD 操作和/或履行基于模板的操作请求。 每个提供程序都可以支持其自己的特定模板类型，并发出唯一或常见类型的实体。
用户配置文件和团队元数据	一种保存与概念团队关联的一组个人的信息的功能，用于对开发人员平台 API 进行分组和访问。 用户与标识提供者帐户密切关联， (例如，Microsoft Entra ID登录) ，但它和团队都可以与任意数量的相关下游系统表示形式相关联。 此信息存储的一个实现是重复使用开发人员平台图。 开发人员自助服务基础可以为用户和团队建立通用实体类型，并将该信息保存在图形中。 但是，为了清楚起见，我们将保持此存储的分离。

这些基础组件使你能够随着时间的推移使用和交换不同的构建基块。 我们将在后续部分更详细地探讨其中的每一个。

我是否必须构建所有这些功能才能开始？

否。 首先，这是一个概念模型，可帮助你思考这样的基础在完成后应该能够执行的操作。 其次，鉴于开发人员平台 API 成为关键接口，实现细节在这里就不那么重要了。 初始实现可能开始在代码中使用接口和类，用于描述的不同层，或者在其他产品中混合使用。 还可以省略一些方面，因为客户开发会告诉你它只是一个较低的优先级。 从你拥有的东西开始，并成长。

考虑到这一点，让我们更深入地了解每一部分。

开发人员平台 API

应定义一个开发人员平台 API 来充当系统的协定。 API 由不同的用户界面用于启用数据访问或驱动预配和其他操作。

此 API 还应充当重要的身份验证和安全层，方法是将其他系统中原始基础 API 的访问限制为更具体、更受控的数据和操作。 API 提供对自己的用户配置文件表示形式的访问权限、用户在平台中的高级角色 (团队成员、管理员等 ) 以及主要标识提供者系统标识符。 有关详细信息，请参阅 用户和团队。

开发人员平台提供程序

鉴于内部开发人员平台的广度，建议创建或查找遵循可扩展提供程序模型的系统，以将功能引入 API。 其理念是，通过与具有明确定义的接口的可插入组件交互来提供自动化和数据聚合等关键功能。 这种松散耦合有助于以增量方式连接所需的内容，并改进可维护性，因为您可以独立于基础的其余部分测试功能。

这也是为平台启用可缩放 的内部源 心态的一个重要方法。 通常，由于持续维护存在挑战，围绕平台工程的内部采购工作无法获得牵引力。 其他团队可能愿意贡献功能，但不太可能愿意在平台的核心内部维护和测试某些内容。 相反，任何集中式团队在维护贡献的代码甚至查看拉取请求方面的能力都有限。 开发人员平台提供商的概念通过允许独立编写的代码“插入”开发人员自助服务基础中的核心功能来缓解这种紧张。 尽管应仔细管理所使用的提供程序、查看任何提供商代码并限制给定提供商可以在开发人员平台中访问的表面区域，但可插入方法可以通过在组织更广泛的部分扩展工作量来帮助你完成更多工作。

关键开发人员平台提供程序概念

实体

实体的概念是内部开发人员平台中的开发人员或其他系统需要跟踪、更新、演示或采取行动的内容。 实体可以彼此有关系，如果组合在一起，则构成一个 图形 ，提供有关内部开发人员平台的各个部分的关键信息。 然后，开发人员平台提供程序可以输出实体来启用核心功能，包括：

• 显示外部预配的资源/环境或可用 API 以供发现和使用
• 公开依赖项分析、影响分析、发现等的关系。
• 显示用于发现和协作的维护者/所有权信息
• 显示更多数据以用于用户体验

将此功能封装到定义完善的开发人员平台提供程序接口中可以简化集成和测试，实现独立部署，并允许主要内部开发人员平台团队外部的开发人员参与和管理提供程序。 这在大型或部门组织中非常重要，因为并非所有工具、服务或平台都集中管理，但更广泛的组织仍希望共享功能。 因此，即使你最初没有走这条路，这也是需要长期考虑的事情。

通用属性

每个实体都应具有一组通用属性，以允许基础管理它们。 要考虑的一些属性包括：

• 唯一标识符
• 名称
• 发起提供程序
• 可选关联到：
  • 拥有用户
  • 拥有团队
  • 其他实体

用户和团队属性非常重要，原因有三：基于角色的访问控制 (RBAC) 、发现和数据聚合 (如团队级摘要) 。 从一开始就在 RBAC 中构建对于安全性以及随着时间的推移扩展内部开发人员平台至关重要。 鉴于开发是一项团队运动，发现与谁谈论实体将很快成为重用、支持和内部资源的关键。

通用实体和特定于提供程序的实体

还应能够建立一组通用的高级规范化实体，多个提供程序可以输出这些实体。 例如：

• 环境
• 资源
• Api
• 存储 库
• 组件
• 工具

它们通常应该处于较高级别，就像放置在 C4 模型 上下文 中或大多数高级 组件 关系图中一样。 例如，对于环境，无需包含内部基础结构地形的详细信息：只需提供足够的信息来列出和关联同一 UX 中来自多个提供程序的不同概念环境。 实体可以指向系统外部较低级别的详细信息，而不是尝试使用所有内容。 它们为发现提供了起点，这些发现是随时间推移启用数据聚合的核心。

其他类型特定于特定用例或提供程序，因此应考虑如何随时间推移适应一组不断增长的实体类型。

模板

在此上下文中，模板的概念与实体的概念不同，因为它们旨在驱动操作。 示例方案包括基础结构预配、创建存储库和其他长时间运行的过程。 这些模板还应通过可扩展的开发人员平台提供程序提供，并且应支持与实体相同的通用属性，包括实体关联。

但是，它们还可以定义执行操作所需的输入，无论是系统还是用户指定。 这些范围从命名资源到可选添加等任何内容。

模板示例包括：

• 基础结构即代码 (IaC) 模板
• ( “右启动”) 或模板存储库的应用程序模板
• 生成管道/工作流模板
• 部署管道/工作流模板
• 参数化脚本
• 参数化 Power Automate 流 (示例：HTTP 请求触发的云流)
• Email模板

与实体一样，模板可以包含提供程序特定的属性。

每个模板可能具有提供程序唯一的不同表示形式。 范围可能包括 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。

幸运的是，扩展开发人员平台提供商的概念以涵盖触发和跟踪自动化步骤可以提供这种所需的抽象。 请考虑下图：

下面是一般概念：

1. 模板可以选择指定用户可以输入的一组输入。 当开发人员触发特定操作时，他们选择模板 (，即使未按这种方式描述) 并输入任何输入。
2. 对模板相关输入的引用将成为开发人员平台 API 中的请求。
3. 提交请求后，业务流程协调程序中的请求路由和处理组件将开始跟踪请求的生命周期。 请求中的请求路由和处理组件将模板路由到模板源自的开发人员平台提供程序。
4. 然后，开发人员平台提供商将执行其实现的相应步骤。
5. [可选]开发人员平台提供程序在执行操作时更新请求状态。
6. 满足请求后，开发人员平台提供商可以返回一组实体，以在开发人员平台图中添加/更新。 这些实体可以是特定于提供程序的实体，也可以是通用实体。

（可选）若要支持更高级的交互，可以允许这些开发人员平台提供程序直接调用开发人员平台 API，以获取更多实体作为输入，甚至请求其他相关操作。

虽然要评估的特定解决方案或产品可能会有所不同，但这应该能让你了解要查找的品质。

考虑到这一点，你需要有一个使用常规任务或工作流引擎的开发人员平台提供程序。 更具体地说，你需要一些内容来桥接作为 应用软件工程系统的一部分组合在一起的内容。 你可能会投资的一个常规工作流或任务执行引擎是 CI/CD 系统。

使用 GitHub Actions 或 Azure Pipelines 的示例

让我们简要了解一下开发人员平台提供商GitHub Actions或 Azure Pipelines 的工作原理。

对于GitHub Actions，实现此工作的关键是开发人员平台提供程序可以连接到指定的 GitHub 实例，并使用 Actions REST API 触发工作流调度事件来触发工作流运行。 通过将 workflow_dispatch 配置添加到工作流 YAML 文件，每个工作流都可以支持一组输入。 Azure DevOps 触发器 类似，还可以使用 Azure DevOps 管道 API 进行运行。 你可能会在其他产品中看到相同的功能。

这些工作流/管道不需要位于应用程序源代码存储库中。 概念是利用这一事实来执行如下操作：

1. 平台工程师或 DevOps 团队成员可以在开发人员自己无法访问的一个或多个中央存储库中维护工作流/管道，但开发人员平台提供商已设置为使用。 同一存储库可以包含工作流/管道使用的脚本和 IaC 代码片段。
2. 若要允许这些工作流/管道与相应的下游系统交互，运营或平台工程团队的其他成员可以在中心存储库中添加所需的机密。 有关如何执行此操作的详细信息，请参阅GitHub Actions和 Azure DevOps 文档，也可以选择使用 Azure 密钥保管库 之类的内容来集中机密。
3. 然后，这些工作流/管道可以遵循一个模型，将任何生成的实体作为生成/部署项目发布 (GitHub 文档、 Azure DevOps 文档) 。
4. 在运行期间，开发人员平台提供程序随后可以watch工作流/管道的状态，并在业务流程协调程序中更新生命周期状态，直到完成。 例如，可以将 Web 挂钩与 GitHub Actions 结合使用，将服务挂钩与 Azure Pipelines 配合使用来跟踪更新。
5. 完成后，提供程序即可根据需要使用已发布的项目以包含在开发人员平台图中。

最后，可以设置此开发人员平台提供程序，将一组模板输出到开发人员平台图中，这些模板引用相应的存储库和工作流/管道，以及给定任务的输入。

使用 CI/CD 系统的最大之处在于，它们通常设置为支持运行任意 CLI，因此不需要一流的、唯一的集成来执行所有操作。 可以根据需要随时间推移添加这些内容。

此示例中介绍的大部分内容都适用于其他类型的提供程序的运行方式。 同样需要注意的是，在此上下文中使用 GitHub Actions 或 Azure Pipelines 不需要也将它们用于实际的 CI/CD 管道。

其他示例

下面是可处理模板的其他类型的开发人员平台提供程序的一些示例。

示例	描述
源代码管理操作	在某些情况下，可能需要创建或更新存储库、提交 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 之类的内容，都可以在开发人员平台提供商中使用相同的基于模板的模型。 你甚至可以随着时间推移转到自动化程度更高的步骤。

虽然你可能不需要所有这些提供程序来启动，但你可以看到如何通过开发人员平台提供程序之类的扩展性来帮助自动化功能随着时间的推移而增长。

用户和团队

平台工程本质上是一个多系统事务，因此，通过将这些系统集成在一起，规划自助服务基础应如何处理更具挑战性的问题非常重要。 在本部分中，我们将介绍一个策略，用于解决标识、用户和团队的常见挑战。

首先，请考虑以下两项建议：

建议	描述
将开发人员平台 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) ，开发人员平台提供商可以watch存储库中的文件更改，并将其缓存在用户配置文件和团队元数据存储中。 或者，可以直接与 Azure 开发人员中心项目 （已提供这些核心 RBAC 构造）集成。

在团队或用户级别建立与下游系统集成的模型

虽然某些开发人员和操作工具/服务会直接以本机方式集成和使用标识提供者概念，但许多工具会将其抽象化为自己的组或用户 (表示形式，即使使用 SSO) 也是如此。 除了启用跨工具的访问之外，这种现实还可能会给数据聚合带来问题。 具体而言，你可能会发现下游系统中的 API 使用自己的标识符而不是标识提供者标识符 (示例：Entra ID 中的对象 ID 不直接) 使用。 这使得筛选和关联用户或团队级别的数据变得困难，除非可以在不同的 ID 之间进行映射。

解决团队和组级别差异

通过 TaC 等模式，可以存储和访问每个系统团队或组标识符之间的关系，以便可以在它们之间进行映射。 概括而言，安全、可审核的 Git 存储库将成为团队的来源，PR 提供受控的用户界面进行更新。 然后，CI/CD 系统可以更新下游系统，并保留用于执行此操作的团队的相关标识符关系。

例如，这样就可以在 API 调用中存储以下关系：

如果希望使用团队存储库中的文件以外的数据源，可以使用开发人员平台业务流程协调程序来应用这一通用概念来完成相同的任务。 在此模型下，团队数据源的开发人员平台提供程序可以触发团队更新事件，所有其他提供程序将根据需要接收和处理该事件。

解决用户 ID 质询

数据访问和聚合的另一个相关挑战是用户 ID 差异。 与团队案例一样，如果使用系统到系统集成来查询有关用户的数据，则不能假设标识提供者本机 ID (示例 Entra ID) 支持给定 API。 同样，存储通过开发人员平台 API 访问数据的用户 ID 的映射可能会有所帮助。 例如，请考虑 GitHub：

对于每个系统，如果可以通过没有用户令牌的 API 对另一个系统的用户 ID 进行查找，则给定的开发人员平台提供商可以动态生成此映射。 在某些情况下，这可能会变得复杂，因为可能需要批量执行此操作，并缓存结果以供参考以保持性能。

使用多个用户令牌回退

如果提供程序需要访问用户级别数据，但无法执行有效用户 ID 转换，则可以设置开发人员平台 API 来管理多个用户令牌。 例如：

1. 开发人员平台 API 可以支持缓存提供程序特定的用户令牌，以用于下游系统。
2. 与 API 触发的给定提供程序的任何交互都将包含在提供程序的用户令牌中（如果可用）。
3. 若要处理没有可用的用户令牌的情况，提供程序会触发 OAuth 流来获取一个令牌。
4. 首先，开发人员平台 API 会传递 OAuth 流的身份验证 URI，其中包含传递到提供程序的重定向 URI。 传入的 URI 将包含 nonce/一次性使用代码。
5. 然后，API 使用 URI 返回“未经过身份验证”的响应。
6. 然后，任何 UX 都可以使用此 URI 在浏览器中驱动相应的身份验证流。
7. 重定向发生后，开发人员平台将收到所需的用户令牌，并将其连同用户 ID 一起缓存以供将来参考。
8. 然后，客户端可以重试 API 调用，这会成功。

此概念概述了一种处理复杂身份验证的方法，因为可以在可能的情况下重复使用 ID，并且不需要为每个下游系统维护单独的重定向 URI。

聚合数据并提供额外功能

使用上下文感知深层链接，指向工具和报告系统

到目前为止，我们一直在讨论问题空间的自动化方面。 这一点可能大有裨义，因为 UI 可以使用在自动化期间返回的实体中的值为团队创建到其他系统的深层链接。

即使与自动化无关，开发人员平台提供程序也可以发出任何类型的实体需求。 但是，通常不希望将整个内部开发人员平台中的所有详细数据引入开发人员平台图。 可观测性解决方案（如 Grafana、Prometheus、DataDog 或 SonarQube）中的代码智能中的仪表板，以及 GitHub 和 Azure DevOps 等 DevOps 套件中的本机功能都非常强大。 相反，最佳方法是创建与这些其他系统的深层链接。 实体可以提供足够的信息来创建链接，而无需直接包含日志内容等详细信息。

对于需要跨工具聚合和汇总数据或需要驱动自定义指标的情况，报表解决方案 Power BI 或 Microsoft Fabric 可以是你的下一个调用端口。 若要合并团队数据，可以连接到 Foundation 的数据库或通过开发人员平台 API。 例如，如规划和优先级中所述，可能需要自定义仪表板的一个位置正在衡量内部开发人员平台的成功。

选择构建的每个额外体验

虽然重新创建常见门户中的现有功能可能很有吸引力，但请记住，你还需要维护它。 这是遵循产品思维模式非常重要的领域。 仪表板样式界面易于构思和理解，但开发人员可能会在其他位置找到更多价值。

也就是说，此处的模型允许使用开发人员平台图中的聚合数据来创建自定义用户体验。 实体应具有内置支持，以便它们可以与用户或团队绑定。 这样，开发人员平台 API 就可以使用索引和缓存) 来限定输出 (范围。

但是，即使需要创建自定义 UX 而不是深层链接，将所有数据拉取到开发人员平台图中通常也不是最佳方法。 例如，假设你可能想要在 UX 中显示已具有明确定义和管理的主页的日志的情况。 使用相关实体中的信息来帮助 UX 直接从下游系统收集信息。

若要开始，可能需要使用系统到系统集成进行连接，但实现 用户和团队中所述的模型之一后，如有必要，可以使用任何存储的下游用户/团队 ID 或用户身份验证令牌。

下面是一些需要考虑的常见体验示例：

示例	描述
发现和探索	正如一位平台工程从业者所说，“减缓项目的是沟通，而不是开发人员技能。 由于软件是一项团队运动，因此创建一个用户界面来帮助发现团队，而他们拥有的实体通常是首先要处理的事情之一。 跨团队搜索、发现和文档有助于促进重用，并帮助协作进行内部采购或支持。 Teams 还可以通过一站式服务来查找自己拥有的内容，包括环境、存储库和其他资源（如文档）。
手动注册环境或资源	虽然可以通过开发人员平台业务流程协调程序预配和跟踪许多内容，但你可能还希望注册已存在或尚未自动化的资源或环境。 从 git 存储库获取信息并将信息添加到资源/环境管理中的简单提供程序在这里很有用。 如果已有软件目录，这也将成为将其集成到模型中的一种方式。
API 目录	开发人员应使用的跟踪 API 可能会大有作为。 如果还没有一些内容，甚至可以从一个简单的 Git 存储库开始，其中包含一系列表示 API 及其状态的文件，使用 PR 来管理审批工作流。 这些可以添加到开发人员平台图中，以便可以显示它们或与其他实体关联。 若要获得更可靠的功能，可以集成 Microsoft API 中心 或其他产品。
许可证符合性	在某些情况下，你可能还希望提供软件许可证合规性和席位使用情况的可见性。 开发人员平台还可以添加使用席位所需的自动化，但即使 (手动分配席位（例如，通过 Git 存储库) 中的 PR 过程），开发人员仍可了解其 (的内容，以及管理员查看) 所有内容的能力。
Kubernetes 以应用程序为中心的视图	使用共享 Kubernetes 群集时，开发人员可能很难通过群集管理员 UX 查找和了解其应用程序的状态。 不同的组织选择以不同的方式处理此问题，但使用命名空间表示应用程序是一种众所周知的方法来执行此操作。 在此处，可以使用实体在群集中的应用程序命名空间与团队之间建立关联，并为应用程序创建更侧重于开发人员的状态视图，并提供指向其他工具或 Web UI 的深层链接。

用户体验

组织中的不同角色将具有代表其日常工作重心的工具或服务。 这些系统的拉动可能会使这些重力中心以外的新用户体验难以获得牵引力。 在完美的世界中，开发人员、运营和其他角色可以继续在对他们有意义的环境中工作，通常是他们已经在使用的环境。

考虑到这一点，在平台工程旅程中取得进展时规划多个用户界面是一个好主意。 这还可以提供一个机会，以开始简单，证明价值，并根据需要发展到更复杂的接口。

集成你拥有的内容

如果已阅读应用软件工程系统和优化应用程序平台文章，则可能确定了想要继续使用的系统。 在任一情况下，在开始从头开始构建新体验之前，请评估是否可以增强和扩展已有的内容。 (问问自己，人们是否会对另一个新的用户体验或他们现在拥有的改进版本做出更好的反应？)

要继续使用的某些工具、实用工具或 Web 应用将是自定义的，这些是增强功能的良好候选项。 但不要忘记注意你最喜欢的工具和服务是否具有可以使用的扩展性模型。 从那里开始，你会得到很多好处。 这可以消除维护和安全方面的难题，让你专注于尝试解决的问题

例如，你可能能够扩展已使用的以下图面：

• 编辑器 和 IDE。
• DevOps 套件。
• CLI 也越来越可扩展。
• Power Pages 等低代码/无代码环境。

与从头开始设置的某个角色相比，每个角色都可能提供更好的起点，因为它们是现有的重力中心。 使用通用开发人员平台 API 作为基线，可以交换内容、试验和随时间推移进行更改。

考虑使用 Web 编辑器扩展来创建开发人员门户

如果你正在寻找面向开发人员的基于 Web 的体验，请记住，最近的趋势是基于 Web 的编辑器和 IDE 版本。 许多（如使用 VS Code 的那些）都有扩展支持。 使用 VS Code，你为这些 Web 体验构建的任何内容随后会在本地进行转换，获得双重优势。

除了 GitHub Codespaces 等服务之外， vscode.dev 是 VS Code 编辑器的免费 Web 版本，无需计算，但支持 某些类型的扩展 ，包括那些使用 Web 视图 进行自定义 UI 的扩展。

即使开发人员不使用 VS Code 本身，UX 模式也是众所周知的，可以在其他开发人员工具中找到。 除了工具本身之外，使用 vscode.dev 还可以为开发人员体验提供方便且熟悉的基于 Web 的基础。

这些可以充当以开发人员为中心的门户，采用熟悉的形式，也可以转换为本地使用。

ChatOps

另一个经常被忽略的机会是实现 ChatOps 接口。 鉴于 ai 产品（如ChatGPT和GitHub Copilot）的兴起，基于聊天的界面增加，操作命令或斜杠命令可以提供一种有用的方法来触发自动化工作流、检查状态等。 鉴于大多数应用程序 CI/CD 平台都对 Microsoft Teams、 Slack 或 Discord 等系统提供开箱即用支持，因此这可以自然地与其他用户界面开发人员集成，相关操作角色每天都使用。 此外，所有这些产品都具有扩展性模型。

投资新的开发人员门户

假设没有想要用作基础的现有门户或界面，则可以决定生成新的开发人员门户。 将此视为目标，而不是起点。 如果你还没有一个与你合作的开发团队，则开始此工作就是这样做的时候了。 每个组织都是不同的，因此对于这种体验中应该提供的内容，没有一刀切的答案。 因此，对于预打包的产品，你目前无法按原样旋转并使用此类产品。

对于自定义生成的自承载选项，常规 Web 门户框架并不新，开发团队可能已在使用你可以利用的框架。 如果尝试在用户面前获取一些内容以获取早期反馈，甚至可以从像低代码 Power Pages 这样简单的内容开始，以连接到常见的开发人员平台 API。

最近的开发人员门户工作更有意见。 例如， Backstage.io 是最初为满足 Spotify 需求而构建的自定义开发人员门户工具包。 它包含一个 CLI 来帮助启动源树，就像 create-react-app 对 React.js 所做的一样。

作为门户工具包，它需要完成工作才能启动，而自定义需要具备 TypeScript、Node.js 和React的知识。 但是，它的最大之处在于，作为工具包，几乎可以更改任何内容。 它也有自己的软件目录和模板化机制，但不需要它们的使用，并且它有明确定义的方式引入称为插件的新 1^st 和 3^rd 方代码。