应用软件工程系统

改进开发人员自助服务应该是 你在平台工程旅程中解决的第一个问题之一。

开始实现自动化自助服务体验的最简单方法是重复使用现有的工程系统。 这些系统不仅熟悉你和你的内部客户，而且即使初始用户体验不完善，它们也能实现广泛的自动化方案。

本文提供应用工程系统的提示，以应对更广泛的自助服务场景，并详细说明如何将最佳实践集成到模板中，以帮助你正确开始并保持正确。

评估基本 DevOps 和 DevSecOps 实践

工程系统是内部开发人员平台的关键方面。 内部开发人员平台建立在 DevOps 和 DevSecOps 的主要原则之上，以减少所有相关人员的认知负担。

DevOps 结合了开发和作，将人员、流程和技术统一到应用程序规划、开发、交付和运营中。 它旨在改进跨历史上孤立的角色（如开发、IT 运营、质量工程和安全）的协作。 可以在开发、部署、监视、观察和反馈之间建立持续循环。 DevSecOps 将其层次融入此循环，在整个应用程序开发过程中实施持续的安全措施。

以下部分重点介绍更直接地归因于平台工程趋势的改进：标准化路径、自动化基础设施配置（除了应用程序部署）、开发环境设置，以及工具、团队资产和服务的自助服务预配和配置（这些并不直接属于应用程序开发流程中的部分）。

建立所需的铺路路径

如果你已经有多个工具集组成了你的工程系统，那么一个初期决定是，是否希望把这些工具整合为平台工程工作的组成部分，或从一开始就支持多种不同工具。 在此工具集中定义一组预设路径是最有效的，并提升灵活性。

当你开始转向产品思维模式时，可以将这些已经铺设好的路径中的工程系统视为一系列由中心化管理的工具，这些工具为开发团队提供服务。 然后，组织中的单个团队或部门可能会偏离，但预期会单独管理、维护和支付其工具，同时仍遵守任何合规性要求。 这提供了一种在不中断的情况下将新工具引入生态系统的方法，因为你可以评估任何偏离正常路径的内容，以便在未来可能纳入铺设路径。 正如一个平台工程主管所说：

你仍然可以做自己的事，但要朝着我们所前进的方向进行。 你可以更改所需的任何一切，但这将成为你的责任。 你掌控改变 – 你持有锋利的刀具。 - 马克，平台工程主管，大型欧洲跨国零售公司

鉴于平台工程的关键目标是转向向内部客户提供价值的产品思维模式，这种星座方法通常比自上而下的任务更有效。 在确立和完善既定路径时，保留一定的灵活性，让团队能够提供反馈并满足特定应用程序的任何真正独特的需求，而不会影响到组织中的其他人。 这导致了一套完全铺通的金光大道，而其他只是部分铺通。 如果没有任何独特的要求，团队承担的额外工作开发自然会导致他们希望随着时间的推移迁移到受支持的路径。

如果您更倾向于采用合并策略，迁移现有应用程序可能比预期的工作量更大，因此，您可能需要首先关注如何在这个领域正确起步，并专注于新项目。 这为你提供了第一条铺好的道路，而现有的所有事物本质上都是未铺好的。 然后，非铺设道路上的开发团队可以考虑一旦新的铺设好的道路显示出其对组织的价值就进行迁移。 此时，你可以进行一场调整活动，通过双向沟通将每个人带至所需状态，因为开发团队将这视为一个好处，而不是税收。 在竞选期间，平台工程团队可以专注于帮助团队迁移，而开发团队则提供有关如何改进铺路的反馈。

无论如何，请避免强制使用铺设好的道路。 最有效的推广铺设路径的方法是强调团队从中获得的益处，而不是依靠强制手段来推行。 由于您的内部开发者平台专注于令这些团队满意，预算和从投资到价值实现的时间压力迫使各个领导自然解决其余的问题。 提出合适的活动，并为那些在未铺设道路上寻找转换办法的人提供双向沟通的渠道。

使用开发人员自动化工具改进铺路的自助服务

创建第一个铺路的一部分应该是建立核心开发人员自动化产品。 在开始考虑启用开发人员自助服务功能时，这些非常重要。

在持续交付期间启用自动应用程序基础结构预配

如果尚未实现，在规划过程中发现的问题可能指向持续集成（CI）和持续交付（CD）可以帮助解决问题。 GitHub Actions、 Azure DevOps、 Jenkins 等产品以及基于拉取的 GitOps 解决方案（如 Flux 或 Argo CD ）存在于此空间中。 可以在 Microsoft DevOps 资源中心开始学习这些主题。

即使已经实现了在现有基础结构中持续部署应用程序的方法，也应考虑使用 基础结构即代码 （IaC）创建或更新所需的应用程序基础结构作为 CD 管道的一部分。

例如，请考虑下图，其中显示了两种使用 GitHub Actions 更新基础结构并部署到 Azure Kubernetes 服务的方法：一种使用基于推送的部署和一个基于拉取的 （GitOps） 部署。

你选择哪一个主要取决于你现有的 IaC 技能集和目标 应用程序平台的详细信息。 GitOps 方法是较新的，在使用 Kubernetes 作为应用程序基础的组织中很受欢迎，而基于拉取的模型目前由于可供选择的选项数量庞大，为您提供了最大的灵活性。 我们预计大多数组织都使用这两者的组合。 不管怎样，精通 IaC 实践可以帮助你了解适用于进一步自动化场景的模式。

在目录或注册表中集中 IaC 以缩放和提高安全性

若要在不同的应用程序中管理和扩展 IaC，您应集中发布 IaC 工件，以便重复使用。 例如，可以在注册表、Bicep 模块、Radius 食谱或 Helm 图表中使用 Terraform 模块，这些图表存储在云原生 OCI 项目注册表（如 Azure 容器注册表（ACR）、DockerHub 或 Azure 部署环境（ADE）中的目录。 对于 GitOps 和 Kubernetes， 群集 API （以及 CAPZ 等实现）可以让你管理 Kubernetes 工作负荷群集，而 Azure 服务操作员 等自定义资源定义可以增加对其他类型的 Azure 资源的支持。 其他工具（例如 Crossplane ）支持跨多个云的资源。 这些工具允许你在类似 ACR 的平台上使用集中式或常见的 Helm 图表，以适应更广泛的场景。

集中 IaC 可以更好地控制谁可以进行更新，因为它们不再随应用程序代码一起存储，从而提高安全性。 当专家、运维或平台工程师进行必要的更改时，代码更新期间因无意更改而导致意外中断的风险较小。 开发人员也受益于这些构建基块，因为它们不必自行创作完整的 IaC 模板，并自动受益于编码的最佳做法。

所选的 IaC 格式取决于现有技能集、所需的控制级别以及使用的应用模型。 例如，Azure 容器应用（ACA） 和最近的实验性 Radius 开源孵化项目比直接使用 Kubernetes 更有指导性，但也简化了开发人员的体验。 若要了解不同模型的优缺点，请参阅 “描述云服务类型”。 不管怎样，引用集中化和可管理的 IaC，而不是在源代码树中具有完整定义，会带来显著的优势。

以一种开发人员无法直接访问的方式持久化任何所需的预配身份或机密，为治理奠定了基本的构建基块。 例如，请考虑此图示，说明可以使用 Azure 部署环境 （ADE） 实现的角色分离。

在这里，平台工程师和其他专家开发 IaC 和其他模板并将其放置在目录中。 然后，操作人员可以按环境类型添加托管标识和订阅，并分配允许使用它们进行资源配置的开发人员和其他用户。

然后，开发人员或 CI/CD 管道可以使用 Azure CLI 或 Azure 开发人员 CLI 预配预配置和控制的基础结构，甚至无需访问所需的基础订阅或标识。 无论你是否使用 ADE 之类的内容，所选的持续交付系统都可以通过将机密和采购 IaC 内容与开发人员无法访问或修改的位置分开来帮助你安全地更新基础结构。

在应用程序持续交付以外的方案中启用自助服务

虽然 CI 和 CD 概念与应用程序开发相关，但内部客户想要预配的许多内容并不直接绑定到特定应用程序。 这可以是共享基础结构、创建存储库、预配工具等。

若要了解这可能有所帮助的位置，请考虑你当前拥有基于手动或基于服务台的进程的位置。 对于每个问题，请考虑以下问题：

• 此过程的发生频率是多少？
• 过程是否缓慢、容易出错或需要大量工作才能实现？
• 由于所需的审批步骤或只是缺乏自动化，这些流程是手动的吗？
• 审批者是否熟悉源代码管理系统和拉取请求流程？
• 流程的审核要求是什么？ 这些是否与源代码管理系统的审核要求不同？
• 在转到更复杂的进程之前，是否可以从风险较低的进程开始？

将频繁、高工作量或容易出错的进程识别为先自动执行的潜在目标。

使用所有内容作为代码模式

除了 Git 无处不在之外，Git 的一个好事是，它旨在成为一个安全的、可审核的信息源。 除了提交历史记录和访问控制之外，拉取请求和分支保护等概念还提供了一种建立特定审阅者、对话历史记录或自动检查的方法，这些检查必须在合并到主分支之前通过。 结合例如在 CI/CD 系统中找到的灵活任务引擎，你拥有一个安全的自动化框架。

作为代码的所有内容背后的想法是，可以将几乎所有内容转换为安全 Git 存储库中的文件。 然后，连接到存储库的不同工具或代理可以读取内容。 将一切视为代码有助于通过模板化实现可重复性，并简化开发人员自助服务。 我们来看看几个这方面的示例。

将 IaC 模式应用于任何基础结构

尽管 IaC 获得了帮助自动执行应用程序交付的普及，但模式扩展到你可能想要预配和配置的任何基础结构、工具或服务，而不仅仅是那些绑定到特定应用程序的基础结构、工具或服务。 例如，在共享 Kubernetes 集群中安装了 Flux 后，可以为多个团队和应用程序提供如 DataDog 之类的服务，甚至可以设置您喜爱的协作工具。

其工作方式是，你有一个单独的 安全的 集中式存储库，其中包含一系列文件，这些文件表示应预配和配置的内容（在这种情况下，从 Bicep 或 Terraform 到 Helm 图表和其他 Kubernetes 本机格式的任何内容）。 运营团队或其他一组管理员拥有存储库，开发人员（或系统）可以提交拉取请求（PR）。 这些 PR 在管理员合并到主分支后，应用程序开发过程中使用的同一 CI/CD 工具可以随之开始处理这些更改。 请考虑下图，其中显示了 Azure 部署环境中包含的 GitHub Actions、IaC 和部署标识：

如果已在使用 GitOps 方法进行应用程序部署，也可以重复使用这些工具。 结合 Flux 和 Azure 服务操作员 等工具，可以在 Kubernetes 外部扩展：

无论哪种情况，你都有一个完全托管、可重现和可审核的信息源，即使生成的内容不是针对应用程序。 与应用程序开发一样，所需的任何机密或托管标识都存储在管道/工作流引擎或预配服务的本机功能中。

由于提出 PR 的人员无权直接访问这些敏感信息，因此它为开发人员提供了一种安全执行操作的方法，即使他们没有直接权限执行这些操作。 这允许你遵循最低特权原则，同时仍为开发人员提供自助服务选项。

跟踪已配置的基础设施

在您开始扩展这种方法时，请考虑如何跟踪已配置的基础架构。 Git 存储库是配置的真实来源，但不会告诉你有关所创建内容的特定 URI 和状态信息。 但是，遵循一切皆代码的方法，为你提供了一个可利用的信息来源，用于综合预配置的基础设施清单。 您的供应商也可能是您可以利用的良好信息来源。 例如，Azure 部署环境包括开发人员可了解的环境跟踪功能。

若要了解有关跨各种数据源跟踪的详细信息，请参阅 设计开发人员自助服务基础。

将安全代码化模式和策略代码化模式应用

虽然预配基础设施非常重要，但确保这些环境安全并始终遵循组织政策同样重要。 这导致了 策略作为代码 概念的兴起。 在这里，源代码管理存储库中的配置文件可用于执行驱动器安全扫描或应用基础结构策略等作。

许多不同的产品和开源项目都采用了此方法，包括 Azure Policy、 开放策略代理、 GitHub 高级安全性以及 GitHub CODEOWNERS 等。 选择应用程序基础结构、服务或工具时，请务必评估它们支持这些模式的方式。 有关优化应用程序和治理的详细信息，请参阅 优化应用程序平台。

将所有内容用作你自己的方案的代码

作为代码的所有内容将这些模式扩展到 IaC 以外的各种自动化和配置任务。 它不仅支持创建或配置任何类型的基础结构，还可以更新任何下游系统中的数据或触发工作流。

PR 成为各种不同进程的良好基线自助服务用户体验，尤其是在入门时。 这些流程自然会获得 Git 本身提供的安全性、可审核性和回滚优势，并且所涉及的系统也会随时间而变化，而不会影响用户体验。

团队即代码化

将一切作为代码应用到你自己的方案的示例是团队即代码模式。 组织应用此模式来标准化团队会员资格，且在某些情况下，在各种系统中标准化开发人员工具/服务权限。 此模式消除了由系统开发人员和操作员的权限管理和用户管理需求驱动的手动入职和卸职服务台流程。 手动服务台流程是潜在的安全风险，因为它有可能过度预配访问权限。 使用团队作为代码模式时，Git 和 PR 的组合可以从可审核的数据源启用自助服务。

有关这种模式的一个成熟和广泛应用的变体示例，请查看 GitHub 的博客文章，了解他们如何管理访问权限。 GitHub 还开源了其复杂的 权利实现， 供你试用或采用。 尽管博客文章描述了所有员工权利，但你可以将团队作为代码概念应用于范围更窄的开发团队方案。 这些开发团队可能根本不在员工组织结构图中表示，并且涉及专有工具或服务，这些工具或服务可能会使加入或卸载团队成员复杂化。

下面是这一想法的简化变体摘要，该变体使用一个 CI/CD 系统和标识提供者的群组协调更新：

在本示例中：

• 每个相关系统都已设置为使用您的标识提供者（例如，Microsoft Entra ID）进行单点登录（SSO）。
• 跨系统使用身份验证提供者组（例如 Entra 组）按角色管理成员资格，以减少复杂性并维护集中式审核。

概括而言，此模式的工作原理如下：

• 锁定的中央 Git 存储库包含一组（通常是 YAML）文件，表示每个抽象团队、相关的用户成员身份和用户角色。 团队更改的所有者或审批者也可以存储在同一位置（例如，通过 CODEOWNERS）。 对这些文件中的用户的引用是标识提供者，但此存储库充当这些团队（但不是用户）的真相来源。
• 这些文件的所有更新都是通过拉取请求完成的。 这将对话及相关参与者与 Git 提交联系起来，以便审核。
• 组长和个人用户可以提交 PR 来添加或删除人员，开发负责人和其他角色可以使用 PR 和模板中的新团队文件创建新团队。
• 每当 PR 合并到 main 中时，都会将 CI/CD 系统绑定到存储库，然后根据需要更新标识提供者系统和所有下游系统。

具体而言，CI/CD 系统：

• 使用适当的身份提供者系统 API，根据文件中的个体准确地为每个角色创建或更新一个身份提供者组。
• 使用每个下游系统的 API 将系统分组概念与每个角色的身份提供者组绑定（例如 GitHub 和 Azure DevOps）。 这可能会导致您团队与下游系统之间形成一对多关系，以便表示角色。
• （可选）使用每个下游系统的 API 来实现绑定到系统分组机制的权限逻辑。
• 使用 API 将锁定数据存储更新为结果（包括关联下游系统团队 ID），然后可用于任何内部生成的系统。 如果需要，还可以存储同一标识提供者用户/帐户的不同系统 ID 表示形式的关联。

如果贵组织已经在使用类似 Entra 权限管理的工具，您可能可以省略在此模式中管理组成员身份的步骤。

你的需求和策略可能会更改细节，但一般模式可以适应任意数量的变体。 与任何下游系统集成所需的任何机密都保留在 CI/CD 系统（例如 GitHub Actions 或 Azure Pipelines 中）或 Azure Key Vault 等内容中。

使用手动或外部触发的参数化工作流

你确定的一些自助服务相关问题可能不利于在 Git 中使用文件。 或者，你可能有一个用于驱动自助服务体验的用户界面。

幸运的是，大多数 CI 系统（包括 GitHub Actions 和 Azure Pipelines）都可以使用输入设置工作流，然后可以通过 UI 或 CLIs 手动触发。 鉴于开发人员和相关运营角色可能已经熟悉这些用户体验，手动触发器可以增强一切皆代码的模式，以便将不具有自然文件表示形式的活动（或作业）实现自动化，或使某些作业完全自动化而不需要经过 PR 流程。

CI 系统可能允许你选择通过 API 从自己的用户体验触发这些工作流或管道。 对于 GitHub Actions，关键是利用 Actions REST API 触发工作流调度事件 来启动工作流运行。 Azure DevOps 触发器 类似，还可以使用 Azure DevOps 管道 API 进行运行。 在其他产品中，可能会看到相同的功能。 无论是手动触发还是通过 API 触发，每个工作流都可以通过将 workflow_dispatch 配置添加到工作流 YAML 文件来支持一组输入。 例如，这就是门户工具包（如 Backstage.io）与 GitHub Actions 交互的方式。

CI/CD 系统的工作流或作业系统无疑会跟踪活动、报告状态，并提供开发人员和运营团队可以用来查看问题的详细日志。 通过这种方式，它具有与一切皆代码模式相同的安全性、可审核性和可见性优势。 但是，请记住，这些工作流或管道执行的任何操作在下游系统中显示为系统标识（例如，Microsoft Entra ID 中的服务主体或托管标识）。

你将了解谁在 CI/CD 系统中启动请求，但你应该评估此信息是否足够，并确保 CI/CD 保留设置符合在此信息至关重要的情况下的审核要求。

在其他情况下，你与之集成的工具可能有自己可以依赖的跟踪机制。 例如，这些 CI/CD 工具几乎总是提供多种通知机制，例如通过 Microsoft Teams 或 Slack 频道。这样，任何提交请求的人都可以获得状态更新，而该频道则提供了发生事件的非正式记录。 这些相同的工作流引擎通常已设计为与作工具集成，以进一步扩展这些模式的有用性。

总结来说，由于 CI/CD 工具及其开箱即用的用户体验的灵活性，可以使用源代码控制存储库中存储的文件来实现一些自动化。 若要了解内部开发人员平台如何在一段时间内不损害更复杂的功能的情况下，将此方法用作起点，请参阅 设计开发人员自助服务基础。

自动设置开发人员编码环境

工程系统中的另一个常见问题是开发人员编码环境启动和规范化。 以下是你可能在此领域了解的一些常见问题：

• 在某些情况下，开发人员可能要花费数周时间才能提交他们的第一次拉取请求。 当你在功能团队和项目之间频繁地调动开发人员（例如，在矩阵型组织中），需要让承包商尽快熟悉工作，或者所属团队正处于招聘阶段时，这是一个有问题的领域。
• 即使对于经验丰富的团队成员而言，开发人员与 CI 系统之间的不一致可能会导致经常出现“它在我的计算机上工作”问题。
• 试验和升级框架、运行时以及其他软件也可能破坏现有的开发环境，导致浪费时间去理清到底出了什么问题。
• 对于开发主管来说，代码评审可能会减缓开发速度，因为评审过程中可能需要进行配置更改，以便进行测试，并在评审结束后撤销这些更改。
• 团队成员和运营商还必须花时间增加开发（运营商、QA、业务、赞助商）以外的相关角色，以帮助测试、查看进度、培训业务角色，并宣传团队正在做的事情。

已有路径的一部分

为了帮助解决这些问题，请考虑将特定工具和实用程序的设置作为定义完善的铺路路径的一部分。 编写开发人员计算机设置脚本可以帮助，可以在 CI 环境中重复使用这些相同的脚本。 但是，请考虑支持容器化或虚拟化开发环境，因为它们可以提供的优势。 这些编程环境可以提前设置以符合您组织或项目的要求。

工作站替换和针对 Windows

如果你着重于 Windows 或想要执行完整的工作站虚拟化（不仅包含项目特定设置，还包括客户端工具和主机操作系统设置），虚拟机通常能提供最佳的虚拟化功能。 这些环境对于从 Windows 客户端开发到 Windows 服务或管理和维护 .NET 完整框架 Web 应用程序的任何内容都很有用。

工作区虚拟化和面向 Linux

如果以 Linux 为目标，请考虑工作区虚拟化选项。 这些选项较少关注于替换开发人员桌面，而更多专注于项目或应用程序特定的工作区。

创建包含保持正确配置的正确启动应用程序模板

代码化一切模式的优势在于，它可以让开发人员沿着从一开始就已规划的路径前进。 如果这对于组织来说是一项挑战，应用程序模板可以快速成为重复使用构建基块以推动一致性、促进标准化并编造组织的最佳做法的关键方法。

首先，可以使用与 GitHub 模板存储库一样简单的内容，但如果组织遵循 monorepo 模式，这可能不太有效。 还可以创建模板，帮助设置与应用程序源树不直接相关的内容。 相反，除了模板化和简化的 CI/CD 设置之外，还可以使用 cookiecutter、 Yeoman 等模板化引擎，或者 Azure 开发人员 CLI （azd）提供一组方便的开发人员命令。 由于 Azure 开发人员 CLI 可用于在所有方案中驱动环境设置，因此它与 Azure 部署环境集成，以提供改进的安全性、集成的 IaC、环境跟踪、关注点分离和简化的 CD 设置。

在拥有一组模板后，开发负责人可以使用这些命令行工具或其他集成的用户体验为他们的应用程序搭建内容结构。 但是，由于开发人员可能无权从模板创建存储库或其他内容，因此这也是使用手动触发、参数化工作流或管道的另一个机会。 你可以设置输入，以便让 CI/CD 系统为其创建从存储库到基础架构的各类内容。

保持正确性和做到正确

但是，为了帮助扩展，这些应用程序模板应尽可能引用集中式构建模块（例如，IaC 模板，甚至 CI/CD 工作流和管道）。 事实上，将这些集中的构建模块视为正确的起始模板可能是解决你确定的一些问题的有效策略。

每个独立的模板不仅可以应用于新应用程序，还可以应用于你打算更新的现有应用程序，这些更新作为推广已更新或改进的指南的合适活动的一部分。 更出色的是，这种集中化有助于保持新的和现有的应用程序保持正确状态，从而不断改进或扩展最佳做法。

模板内容

建议在创建模板时考虑以下方面。

相关内容

• Microsoft的 DevOps 资源中心
• 容器安全供应链框架
• 使用 Azure Pipelines 的 CI/CD 基线体系结构
• 优化应用程序平台