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

充分了解 工程系统的目标后，可以创建更复杂的开发人员自助服务体验。 开发人员自助服务体验基于概念、模式和组件的基础。

虽然你可能暂时不需要这里描述的所有内容，但如果构建自定义方案或评估相关产品，应注意这些概念。 开发人员自助服务体验模型可以由本土、现成和开源产品的组合组成。 产品或开源门户工具包（如 Backstage.io ）可能会对此处介绍的模型的某些元素使用不同的术语，但模型仍可以帮助你确定方向。

自动执行工作流、聚合数据、开始简单和逐步扩展

你的目标是通过受控的、受治理的任务执行和预配，以及集中可见性，通过防护措施实现自助服务。 最值得关注的领域是那些繁琐的领域，或者是开发人员由于复杂性或权限无法自行完成的领域。 最后一部分非常重要，可以让您在不强制开发人员使用手动服务请求流程的情况下，遵循最低特权原则。

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

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

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

通常自助服务体验分为两个主要类别：自动化和数据聚合。

虽然数据聚合创造了良好的用户体验，但自动化更为重要：

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

在 平台工程过程中，你发现了自动化可能解决的问题。 除了减少认知负载和开发人员的辛勤外，自动化还可以帮助确保应用程序连接到最佳工具和服务中，以便作、安全和其他角色完成其工作。

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

可以使用系统集成自动完成基础结构预配等作，但也可以触发并简化手动工作流过程，以便开发人员自动完成。 这对于平台的早期阶段、引入生态系统的新产品或你尚未或无法自动使用系统（例如软件许可证分配）的领域非常有用。 通过正确的设计，可以从 Power Automate 之类的手动流程开始，在一段时间内切换到完全自动化的流程。 因此，从一开始就设计自动化。

首先，通过重用现有投资，例如工程系统或内部门户，进而创建命令行接口、基础网页，甚至 Power Pages、Power BI 或 Microsoft Fabric 仪表板，随着需求的增加进行扩展。 拥有一致的 API，UX 随后使用该 API 有助于随着需求和首选项的变化而支持多个接口。

开发人员自助服务平台组件：API、图形、业务流程协调程序、提供程序和元数据

考虑开发人员自助服务的基础：

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

这些基础组件使你能够随着时间的推移使用和交换不同的构建基块。

我是否需要构建所有这些功能才能开始？

否。 首先，这是一个概念模型，可帮助你思考像这样的基础完成后应该能够做些什么。 其次，鉴于开发人员平台 API 成为关键接口，此处的实现细节不太重要。 您的初始实现可能会在代码中使用接口和类，以实现所描述的不同层或其他产品的混合。 你还可以省略某些方面，因为客户开发的反馈告诉你它的优先级较低。 从已有的资源开始，并逐步成长。

开发人员平台 API

应定义开发者平台 API 作为系统的协定。 不同的用户界面使用 API 来实现数据访问或进行驱动程序管理和其他操作。

此 API 通过将其他系统中底层 API 的访问限制为更具体的受控数据和操作，从而充当重要的身份验证和安全层。 API 提供对其用户配置文件的访问权限，包括用户在平台上的高级角色（如团队成员、管理员等）和主要身份提供商系统标识符的表示形式。 有关详细信息，请参阅 用户和团队。

开发者平台供应商

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

这也是为平台启用可缩放的内部源心态的重要方法。 通常，由于持续维护存在挑战，围绕平台工程的内部采购工作未能获得牵引力。 其他团队可能愿意提供功能，但不太可能愿意维护和测试平台核心内的内容。 相反，任何集中式团队在维护贡献的代码甚至审查合并请求方面的能力都是有限的。 开发平台提供商这一概念通过允许独立编写的代码插入到开发者自助服务基础架构中的核心功能，从而缓解这种紧张关系。 虽然应仔细管理您使用的供应商、检查任何供应商代码，并限制特定供应商在开发者平台中可访问的范围，但可插入的方法可以通过将工作扩展到整个组织的更广泛范围来帮助您完成更多工作。

关键开发者平台提供商概念

Entities

内部开发人员平台中，实体的概念是开发人员或其他系统需要跟踪、更新、呈现或操作的对象。 实体可以彼此有关系，而这些关系组成一个 图，提供关于你内部开发人员平台各个部分的重要信息。 然后，开发人员平台提供程序可以输出实体以启用核心功能，包括：

• 将外部配置的资源/环境或可用的 API 显示出来以供发现和使用
• 暴露依赖分析、影响分析、发现等之间的关系。
• 揭示有助于发现过程和协作的维护者及所有权信息
• 显示更多用于用户体验的数据

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

公用属性

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

• 唯一标识符
• Name
• 原始提供者
• 可选关联到：
  • 所属用户
  • 所属团队
  • 其他实体

由于以下三个原因，用户和团队属性非常重要：基于角色的访问控制（RBAC）、发现和数据聚合（如团队级别摘要）。 从一开始就合并 RBAC 对于安全性至关重要，并不断扩展内部开发人员平台。 鉴于开发是一项团队合作活动，尽快找到有关实体的沟通者，对于重用、支持和内部开源来说至关重要。

常见的和提供者特定的实体

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

• Environments
• 资源
• 应用程序接口
• 存储库
• Components
• Tools

这些通常应位于较高级别，就像在 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 触发工作流调度事件 来触发工作流运行。 每个工作流都可以通过向工作流 YAML 文件添加 workflow_dispatch 配置来支持一组输入。 Azure DevOps 触发器 类似，还可以使用 Azure DevOps 管道 API 进行运行。 在其他产品中，可能会看到相同的功能。

这些工作流或管道不需要位于应用程序源代码存储库中。 这个概念是利用这一事实来进行类似操作。

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

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

使用 CI/CD 系统的好处在于，它们通常设置为支持运行任意命令行界面（CLIs），因此不需要专门的集成来完成所有工作。 可以在需要时随时间添加这些。

此示例中介绍的大部分内容都适用于其他类型的提供程序如何发挥作用。 此外，请务必注意，在此上下文中使用 GitHub Actions 或 Azure Pipelines 并不意味着必须将它们用于实际的 CI/CD 管道。

其他示例

下面是能够处理模板的其他类型开发平台供应商的一些示例。

虽然在开始时你可能不需要所有这些提供商，但你可以了解如何通过开发者平台提供商等扩展性，让您的自动化功能随时间增长。

用户和团队

平台工程本质上是多系统事务，因此规划自助服务基础如何处理与将这些系统集成在一起更具挑战性的问题非常重要。 下面是解决标识、用户和团队共同挑战的策略。

在单个标识提供者组之外建立团队的概念

随着平台工程之旅的继续，你可能发现标识提供者组非常适合管理成员身份，但多个组确实需要结合在一起，形成团队的 RBAC 和数据聚合概念。

在平台工程的上下文中，我们将团队定义为一组不同角色的人员，他们共同工作。 对于数据聚合，多职能团队的理念对于在报表仪表板等地方增强发现能力和汇总信息至关重要。 另一方面，组是身份提供者的一般概念，代表一组用户，设计思想是将多人添加到特定角色，而不是反过来。 因此，使用 RBAC，团队可以通过不同的角色与多个标识提供者组相关联。

团队数据的源可能来自几个不同的位置。 例如，如果使用 团队作为代码（TAC）模式，开发人员平台提供程序可以监视存储库中的文件更改，并将其缓存在用户配置文件和团队元数据存储中。 或者，可以直接与拥有这些核心 RBAC 构造的 Azure Dev Center 项目 集成。

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

虽然某些开发人员和运维工具/服务原生地集成并使用标识提供者概念，但许多工具/服务将标识提供者的概念抽象为其自己的组或用户表示，即使在使用 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，该 URI 用于 OAuth 流，其中的重定向 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 而不是深层链接，将所有数据拉取到开发人员平台图中通常也不是最佳方法。 例如，假设你可能想要在 UX 中显示那些具有明确定义和良好管理环境的系统日志。 使用相关实体中的信息来帮助 UX 直接从下游系统收集信息。

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

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

用户体验

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

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

集成所拥有的内容

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

您想继续使用的一些工具、实用工具或 Web 应用可能是定制的，这些是适合增强的优秀候选者。 但不要忘记注意你喜欢的工具和服务是否具有可以使用的扩展性模型。 你将会从在那里开始中获得很多益处。 这可以消除维护和安全难题，让你专注于你试图解决的问题

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

• 编辑器 和 IDE
• 您的 DevOps 套件
• CLIS 也越来越可扩展
• 低代码/无代码环境如 Power Pages

每个角色的起点可能比你从头开始设置的角色提供更好的起点，因为它们是现有的重力中心。 使用通用开发人员平台 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，帮助您启动您的项目结构，就像 create-react-app 对于 React.js 所做的一样。

作为一个门户工具包，它需要一定的努力才能启动，而要进行自定义则需要掌握 TypeScript、Node.js 和 React 的知识。 然而，它最大的事情是，作为一个工具包，你可以更改几乎任何东西。 它也有自己的软件目录和模板化机制，但它们的使用并不是必需的，而且是引入名为插件的新代码的明确方法。

相关内容

• Microsoft Power Pages
• Backstage.io
• 应用软件工程系统