开发人员自助服务平台体系结构
开发人员自助服务体验依赖于概念、模式和工具的组合，涵盖自定义构建、现成和开源技术。 其目标是使开发人员能够执行受控的任务和预配，同时保持集中的可见性。 主要侧重于开发人员无法独立处理的繁琐或过于复杂的任务。
开发人员自助服务平台组件
开发人员自助服务基础包含多个关键组件，这些组件协同工作，可简化和自动化开发人员工作流。 这些组件包括“开发人员平台 API”、“开发人员平台图”、“开发人员平台业务流程协调程序”、“开发人员平台提供程序”，以及“用户配置文件和团队元数据”。
“开发人员平台 API”充当交互的中心点，作为用户体验和其他系统之间的合同接口。 开发人员平台 API 应支持数据访问并通过各种用户界面驱动预配操作。 它充当主要的身份验证和安全层，限制对基础原始 API 以及相应数据和操作的访问。 API 管理用户配置文件、平台中的角色以及主要标识提供者标识符，以确保适当的访问控制。
开发人员平台图是对开发人员平台 API 的补充，这是一种安全的托管数据结构，有助于发现平台中的实体和模板并对其进行关联。 实体聚合来自多个来源的数据，而模板则指导用户输入以实现自动化。
开发人员平台图能够将来自多个提供程序的实体和模板关联到可搜索的结构中。 虽然这些实体的数据不需要直接存储在图形数据库中，但可以缓存与提供程序的交互以及必要的元数据。 此图形在处理由多个提供方提供的常见实体时非常有价值。 例如，API 可能来自 Azure API 中心，而部署和环境可能来自持续部署系统。 该图形通过通用 API 增强用户体验，从而实现发现、搜索和治理。
若要执行基于模板的操作，“开发人员平台业务流程协调程序”将路由和跟踪请求，并与与下游系统集成的专用“开发人员平台提供程序”进行协调。 该业务流程协调程序使开发人员或系统能够使用模板请求操作，而无需直接执行操作。 它与任务引擎、工作流引擎或其他业务流程协调程序协调以执行操作。 此组件对于启用自助服务至关重要，因为它允许开发人员无需直接权限即可触发操作。 与 CI/CD 不同，这些操作并不限于应用程序源代码。 GitHub Actions 或 Azure Pipelines 等工作流引擎可以充当业务流程协调程序，但随着时间的推移，抽象对于支持不同的引擎可能很有用。 借助这种灵活性，可实现引擎迁移，支持后续自动化流程的手动步骤，并适应面向非开发角色的操作（例如应付帐款）。 此外，可以通过 HTTP 请求处理更简单的任务，避免需要复杂的引擎。
“开发人员平台提供程序”管理实体上的创建、读取、更新和删除 (CRUD) 操作的逻辑，以及执行操作请求，支持各种工作流和服务。 该提供程序通过可扩展的提供程序模型将功能引入 API，从而实现自动化和数据聚合等关键功能。 此模型促进松散耦合，允许增量集成新功能并提高可维护性。 通过培养内源心态，平台功能可以由不同的团队提供和维护，从而最大限度地减少中心团队的维护负担。 尽管必须仔细审查提供程序代码和管理访问权限，但这种可插入方法有助于在整个组织中扩展开发工作。
该基础还包括管理“用户配置文件和团队元数据”的功能，它将个人和团队信息与标识提供者（例如 Microsoft Entra ID）托管的帐户相关联。 此元数据用于开发人员平台 API 中的分组和访问控制。 虽然可以将这些信息存储在开发人员平台图中，但将其分开可确保清晰。
开发人员自助服务基础可通过集中式用户界面/用户体验 (UI/UX) 访问。 提供统一的接入点可简化开发人员的交互，促进以无缝直观的方式使用工作流和资源。
开发人员自助服务基础无需从一开始就完全构建。 相反，它可以作为随时间推移而实现的功能目标的概念指南。 可以使用现有工具、接口或类来简化初始实现，以解决通过客户反馈确定的最紧迫的优先事项。 通过从小规模开始和迭代，基础可以发展以有效地满足新的需求。
关键开发人员平台提供程序概念
在开发人员平台中，资源的有效管理和业务流程依赖于实体及其属性和模板的使用。 这些关键概念提供结构和自动化，支持不同提供程序之间的无缝集成，并促进一致的工作流和治理。
实体
实体是开发人员或系统需要在内部开发人员平台中跟踪、更新、呈现或执行操作的关键对象。 这些实体可以相互关联，形成一个提供有关平台的重要信息的图表。 开发人员平台提供程序可以输出实体以支持各种核心功能，例如发现外部资源、执行依赖性分析或显示所有权和维护者信息。 定义完善的提供程序接口可简化集成、测试和部署，同时使开发人员团队能够独立操作。
通用属性
为了有效地管理实体，定义一组通用属性很有帮助。 部分建议的属性包括唯一标识符、名称、原始提供程序以及与用户、团队或其他实体的可选关联。 这些属性对于基于角色的访问控制 (RBAC)、发现和数据聚合非常重要。 从一开始就实现 RBAC 对于安全性和随时间扩展平台至关重要。 用户和团队关联尤其有价值，因为它们有助于发现和协作，从而实现平台内的高效重用、支持和内部溯源。
常见实体和提供程序特定实体
你还应定义多个提供程序可以输出的一组通用的高级规范化实体。 这些实体可以包括环境、资源、API、存储库、组件和工具。 这些实体应该是概念性的，侧重于广泛的分类（例如环境），而不是精细的技术细节（例如内部基础结构）。 这种概括视图有助于发现，随着时间的推移实现数据聚合，同时指向系统外部的较低级别详细信息。 此外，随着平台的发展，可能需要适应越来越多的特定于提供程序的实体类型，以满足不同的用例。
模板
模板设计用于推动基础结构预配、存储库创建或其他长时间运行的进程等操作。 这些模板可通过开发人员平台提供程序获取，包含实体关联和所需输入（例如资源名称）等常见属性。 模板可以表示各种格式，包括基础设施即代码 (IaC) 模板、应用程序模板或参数化脚本。 它们通常特定于提供程序，根据所使用的技术具有不同的表示形式。 这些表示形式的示例包括 Terraform 或 Bicep 模板、Helm 图表、参数化 GitHub Actions 工作流、Azure Pipelines、简单脚本或针对特定提供程序生态系统定制的自定义格式。
尽管无需集中存储模板，但必须可以通过提供程序访问模板，以确保跨平台进行一致的访问。 它们可以存在于不同的存储库、注册表或目录中，具体取决于用例。 例如，GitHub 模板存储库可用于应用程序模板，而 IaC 模板可以驻留在受限的目录存储库中，开发人员可以通过 Azure 部署环境等工具间接访问该存储库。 其他 IaC 模板可能存储在开放容器计划 (OCI) 工件注册表中，例如 Helm 图表。 在某些情况下，模板可能只是引用参数化的 HTTP 终结点。
平台工程师或域专家通常会编写这些模板并与开发团队共享，以供重复使用。 在系统内集中使用模板可以便于访问，同时强制执行组织标准和策略。 此流程有助于维持整个平台的控制和合规性，同时使开发人员能够更高效地工作。
GitHub Actions 作为平台提供程序
为了说明提供程序的工作原理，我们以 GitHub Actions 和 Azure Pipelines 为例。 它们中的任何一个都可以作为开发人员平台提供程序，通过各自的 API（例如 GitHub Actions REST API 或 Azure DevOps Pipeline API）触发工作流或管道运行。 这些工作流或管道不需要存储在应用程序源代码存储库中，使平台工程师能够在中心专用存储库中维护它们。 在此模型中，开发人员无法直接访问工作流，但可以使用开发人员平台提供程序与其进行交互。 提供程序可以通过与 Azure Key Vault 等服务集成来管理必要的机密，例如凭据或 API 密钥。 当工作流执行时，提供程序会跟踪其状态，使用 GitHub Actions 的 Webhook 和 Azure Pipelines 的服务挂钩来监控进度。 工作流完成后，将捕获并发布生成的任何项目，例如构建或部署结果。 可以将这些项目以及输入参数和对工作流的引用添加到开发人员平台图中。 此方法还允许灵活使用任意 CLI，随时间推移支持各种自动化任务。 此外，在此上下文中使用 GitHub Actions 或 Azure Pipelines 独立于其在 CI/CD 中的传统角色，为管理各种流程和模板提供了更广泛的适用性。
此外，还有其他类型的开发人员平台提供程序，可以通过模板处理各种任务。 对于源代码管理操作，提供程序可以帮助管理 Git 任务，例如创建存储库、提交 PR 或其他 Git 操作，而无需依赖常规工作流引擎。 基础结构预配可以通过 Azure 部署环境或 Terraform Cloud 等专用提供程序进行简化，专注于安全高效的基础结构即代码 (IaC)。 应用程序基架提供程序（例如 Azure Developer CLI）支持创建应用程序源树并将其推送到源存储库，从而为不同的生态系统增加灵活性。 手动流程，例如生成拉取请求 (PR) 或为非开发人员自动化执行工作流，也可以通过基于模板的提供程序进行管理，从而逐步实现自动化。 这些示例突出了开发人员平台提供程序随时间如何增强自动化功能的可扩展性和适应性。