设计开发人员自助服务基础
充分了解工程系统的目标后，可以创建更复杂的开发人员自助服务体验。 开发人员自助服务体验基于概念、模式和组件的基础。
虽然你目前可能不需要组织中介绍的所有内容，但如果生成自定义或评估相关产品，则应牢记这些概念。 开发人员自助服务体验模型可以由本土、现成和开源产品的组合组成。 产品或开源门户工具包（如 Backstage.io ）可能会对下面所述的模型的某些元素使用不同的术语，但该模型仍可以帮助你确定方向。
自动执行工作流、聚合数据、开始简单和逐步扩展
你的目标是通过受控的、受治理的任务执行和预配，以及集中可见性，通过防护措施实现自助服务。 最有价值的领域是那些繁琐或开发人员由于复杂性或权限而无法自行执行的操作。 最后一部分对于在不强制开发人员通过手动服务台流程的情况下，遵循最低特权原则非常重要。
虽然可以选择扩展 DevOps 套件以满足这些需求，但可能需要随着时间的推移支持多个 应用程序平台 ，支持它们的特定工具和流程也需要更改。 核心问题是标准是移动目标。 正如一位平台工程从业者所指出的：
困难涉及标准化... 处理“放弃软件”... 由于自动化过程的潜在中断以及识别必要更改的耗时任务，因此通常无法实现标准化。 - Martin，DevOps 工程师，大型物流公司
快速切换到新的或更新的标准通常不可行，放弃现有进程会产生风险。 你的组织可能已经在按方案使用多个 DevOps 套件或各个工具和开发人员服务的不同组合。 即使在中心团队和标准解决方案中，随着自助服务需求的增加，可变性也是不可避免的。 因此，你需要启用受控试验，其中指定团队可能会尝试新技术、部署策略等，然后是有意采用和增量推出。
通常自助服务体验分为两个主要类别：自动化和数据聚合。
虽然数据聚合创造了良好的用户体验，但自动化更为重要：
自动化是关键，将受到所有人的喜爱。 [数据] 聚合是次要的。 – Peter，平台工程主管，跨国科技公司
在平台工程 过程中，你发现了自动化可能解决的问题。 除了减少认知负载和开发人员的辛勤外，自动化还可以帮助确保应用程序连接到最佳工具和服务中，以便操作、安全和其他角色完成其工作。
但是，如果使用多个系统来驱动自动化，则某些级别的数据聚合有助于跟踪自动请求和关联的结果。 首先，可以链接到外部系统以满足其他需求或深入了解详细信息。 数据聚合和可见性对于审核、治理和减少浪费也很重要（例如：未使用的环境）。
可以使用系统集成自动完成基础结构预配等操作，但也可以触发并简化手动工作流过程，以便开发人员自动完成。 这对于平台的早期阶段、引入生态系统的新产品或你尚未或无法自动使用系统（例如软件许可证分配）的领域非常有用。 通过正确的设计，可以从 Power Automate 之类的手动流程开始，在一段时间内切换到完全自动化的流程。 因此，从一开始就设计自动化。
首先，通过重用现有投资（如工程系统或内部门户），然后创建 CLIs、基本网页，甚至 Power Pages、 Power BI 或 Microsoft Fabric 仪表板，并根据需要进行扩展。 拥有一致的 API，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 管道 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 命名空间，或者将 Git 与 GitOps 工作流结合使用（使用 Flux 或 Argo CD 作为特定类型的提供程序）。 更以应用为中心的模型，如实验 性 Radius OSS 孵化项目及其自己的 CLIS 可能会随着时间推移而拥有自己的开发人员平台提供商。 关键是查找和规划扩展性，以便你可以适应。 |
| 应用程序基架/种子设定 | 应用程序模板是平台工程随时间推移导致的重要部分。 你可以通过提供专用的开发人员平台提供程序来支持所选模板引擎，该提供程序不仅设计为应用程序源树搭建基架，还可以创建内容并将其推送到源代码存储库，并将生成的实体添加到图形中。 每个生态系统都有自己的应用程序基架首选项，无论是 Yeoman、cookiecutter 还是 Azure 开发人员 CLI 之类的内容，因此此处的提供程序模型可让你支持同一接口中的多个接口。 同样，这是关键所在。 |
| 手动过程 | 无论是为手动审批自动生成 PR，还是为非开发人员角色手动生成工作流步骤来响应使用 Power Platform 之类的内容，都可以在开发人员平台提供程序中使用基于模板的模型。 你甚至可以在一段时间内移动到更自动化的步骤。 |
虽然你可能不需要所有这些提供程序来启动，但你可以了解通过开发人员平台提供程序等功能如何帮助自动化功能随时间推移而增长。
用户和团队
平台工程本质上是多系统事务，因此规划自助服务基础如何处理与将这些系统集成在一起更具挑战性的问题非常重要。下面是解决标识、用户和团队共同挑战的策略。
| 建议 | 说明 |
|---|---|
| 将开发人员平台 API 直接与标识提供者集成，以实现最佳安全性 | 若要保护开发人员平台 API，我们建议根据其可靠的标识和 Entra ID 的基于角色的访问控制 （RBAC） 功能，直接与标识提供者（如 Microsoft Entra ID）集成。 直接使用标识提供者的本机 SDK 和 API（例如，通过 MSAL Entra ID）而不是通过抽象，有很多优点。 在整个过程中，可以驱动端到端安全性并依赖于同一 RBAC 模型，同时确保 持续评估条件访问策略 （而不是仅在登录时）。 |
| 在下游系统中使用单一登录和标识提供者组集成 | 单一登录（SSO）集成应使用用于开发人员平台 API 的同一标识提供者和租户。 此外，请务必利用对标识提供者组（如 AD 组）中的 SCIM 等协议的支持。 将这些标识提供者组绑在下游系统权限并不总是自动的，但至少可以将标识提供者组与每个工具的分组概念相关联，而无需之后手动管理成员身份。 例如，可以将 GitHub 的企业 托管用户 （EMU）支持与手动利用将标识提供者组绑定到 GitHub 团队的功能相结合。 Azure DevOps 具有 类似的功能。 |
在单个标识提供者组之外建立团队的概念
随着平台工程之旅的继续，你可能发现标识提供者组非常适合管理成员身份，但多个组确实需要结合在一起，形成基于角色的访问控制（RBAC）和数据聚合团队的概念。
在平台工程的上下文中，我们将团队定义为一组在不同角色中协同工作的人员。 对于数据聚合，多角色团队的想法对于在报表仪表板等位置启用发现和汇总信息至关重要。 另一方面，组是一组用户的常规标识提供者概念，旨在将多个人员添加到特定角色，而不是另一种方式。 因此，使用 RBAC，团队可以通过不同的角色与多个标识提供者组相关联。
团队数据的源可能来自几个不同的位置。 例如，如果使用 团队作为代码模式 （TaC），开发人员平台提供程序可以监视存储库中的文件更改，并在用户配置文件和团队元数据存储中缓存它们。 或者，可以直接与 Azure 开发人员中心 Project 之类的内容集成，该项目已提供这些核心 RBAC 构造。
在团队或用户级别建立与下游系统集成的模型
虽然某些开发人员和操作工具/服务将本机集成和使用标识提供者概念，但许多人会将这抽象化为组或用户（即使使用 SSO）。 除了启用跨工具的访问之外，这种现实也可能会给数据聚合带来问题。 具体而言，你可能会发现下游系统中的 API 使用自己的标识符而不是标识提供者标识符（例如：未直接使用 Entra ID 中的对象 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 会通过传递到提供程序的重定向 URI 将 OAuth 流的身份验证 URI 传回。 传入的 URI 将包括 nonce/一次性使用代码。
- 然后，API 使用 URI 返回“未经过身份验证”的响应。
- 然后，任何 UX 都可以使用此 URI 在浏览器中驱动适当的身份验证流。
- 重定向发生后，开发人员平台将收到所需的用户令牌，并缓存该令牌以供将来参考以及用户 ID。
- 然后，客户端可以重试 API 调用，该调用随后会成功。
此概念概述了一种处理复杂身份验证的方法，因为可以尽可能重复使用 ID，并且不需要为每个下游系统维护单独的重定向 URI。
使用上下文感知深层链接来访问工具和报告系统
直到这一点，我们一直在谈论问题空间的自动化方面。 这一点可能很长，因为 UI 可以使用自动化期间返回的实体中的值，为团队创建指向其他系统的深层链接。
即使与自动化无关，开发人员平台提供程序也可以发出任何类型的实体需求。 但是，通常不希望将整个内部开发人员平台中的所有详细数据引入开发人员平台图。 可观测性解决方案（如 Grafana、Prometheus、DataDog 或 SonarQube）中的代码智能以及 DevOps 套件（如 GitHub 和 Azure 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 应用是自定义的，这些是增强的优秀候选项。 但不要忘记注意你喜欢的工具和服务是否具有可以使用的扩展性模型。 从那里开始，你会从中受益匪浅。 这可以消除维护和安全难题，让你专注于你试图解决的问题
例如，你可能能够扩展你已经在使用的以下图面：
每个角色的起点可能比你从头开始设置的角色提供更好的起点，因为它们是现有的重力中心。 将常见的开发人员平台 API 作为基线，可让你交换内容、试验和随时间变化。
考虑使用 Web 编辑器扩展创建开发人员门户
如果你正在寻找面向开发人员的基于 Web 的体验，请记住，最近的趋势是基于 Web 的编辑器和 IDE 版本。 许多（如使用 VS Code）的扩展支持。 使用 VS Code 时，为这些 Web 体验构建的任何内容随后会在本地进行翻译，以获取双重权益。
除了 GitHub Codespaces 等服务之外，vscode.dev 是没有计算的 VS Code 编辑器的免费 Web 版本，但包括支持某些类型的扩展，包括那些对自定义 UI 使用 Web 视图的扩展。
即使开发人员不使用 VS Code 本身，UX 模式也是众所周知的，并且可以在其他开发人员工具中找到。 除了工具本身之外，使用 vscode.dev 还可以为开发人员体验提供方便且熟悉的基于 Web 的基础。
这些门户可以充当以开发人员为中心的门户，以熟悉的形式进行转换，也可以转换为本地使用。
ChatOps
通常被忽视的另一个机会是实现 ChatOps 接口。 由于聊天产品（如 ChatGPT 和 GitHub Copilot）的兴起，基于聊天的接口的增加，操作命令或斜杠命令可以提供触发自动化工作流、检查状态等的有用方法。 鉴于大多数应用程序 CI/CD 平台都对 Microsoft Teams、Slack 或 Discord 等系统提供现成的支持，这可以自然地与另一个用户界面开发人员和相关操作角色集成，并且每天都使用相关操作角色。 此外，所有这些产品都具有扩展性模型。
投资新的开发人员门户
假设你没有要用作基础的现有门户或界面，则可以决定构建新的开发人员门户。 将此视为目的地，而不是起点。 如果你还没有一个开发团队与你合作，请开始此工作是执行此操作的时间。 每个组织都是不同的，因此对于这种体验中应该是什么，没有任何一个大小拟合的答案。 因此，预包装产品没有事实答案，你可以启动和使用原样用于今天这样的内容。
对于自定义的自承载选项，常规 Web 门户框架并不新，并且开发团队可能已使用可点击的选项。 如果尝试在用户面前获取某些内容以获取早期反馈，则甚至可以从低代码 Power Pages 开始，以连接到常见的开发人员平台 API。
最新的开发人员门户工作更有意见。 例如， Backstage.io 是一个自定义开发人员门户工具包，最初是为了满足 Spotify 的需求而构建的。 它包括一个 CLI，可帮助启动源树，就像创建-react-app 针对React.js所做的那样。
作为门户工具包，它需要工作才能启动，自定义需要了解 TypeScript、Node.js 和 React。 然而，它最大的事情是，作为一个工具包，你可以更改几乎任何东西。 它也有自己的软件目录和模板化机制，但它们的使用并不是必需的，而且它具有明确的方法来引入名为插件的新 1st 和 3rd party 代码。