应用软件工程系统

一旦你了解了想要在平台工程 旅程中首先解决的问题，改进开发人员自助服务可能会排在榜首。 开始启用自动化自助服务体验的最简单方法之一是重复使用现有的工程系统。 你和你的内部客户不仅熟悉这些系统，而且即使初始用户体验不美观，它们也能实现广泛的自动化方案。

本文将提供一些提示，介绍如何应用工程系统来处理更广泛的自助服务方案，以及如何将最佳做法封装到模板中，帮助你正确开始并保持正确。

评估基本 DevOps 和 DevSecOps 实践

工程系统是内部开发人员平台的关键方面。 但是，如果没有任何系统至少针对 DevOps 和 DevSecOps 的一些main租户，则你确定的问题可能会告诉你从那里开始。 内部开发人员平台从中构建，以减少涉及的每个人的认知负载。

概括而言，DevOps 将开发和运营相结合，将人员、流程和技术与应用程序规划、开发、交付和运营结合起来。 它旨在改善开发、IT 运营、质量工程和安全等历史孤立角色之间的协作。 在开发、部署、监视、观察和反馈之间建立连续循环。 在整个应用程序开发过程中，DevSecOps 通过持续的安全做法将 DevSecOps 分层到此循环中。

Microsoft 的 DevOps 资源中心 是查找所需流程和系统类型建议的绝佳场所，因此本部分不会对此进行深入介绍。 随着你前进，这些成为基本要素。 不要忘记将最近的 DevSecOps 主题（如 容器供应链安全性 ）纳入计划。

有关持续反馈的详细信息，请参阅 要考虑的指标。 还可以在 优化应用程序平台中详细了解用于可观测性、监视和持续反馈领域的工具。

在本文的其余部分，我们将重点介绍更直接地归因于平台工程运动的改进：铺平路径、自动化基础结构预配 (，以及应用程序部署) 、编码环境设置，以及自助预配和配置不属于应用程序开发循环的工具、团队资产和服务。

建立所需的铺面路径

如果你已经拥有多个构成工程系统的工具集，则需要提前做出一个决定，即是想要在初始平台工程工作中整合它们，还是要从一开始就支持一系列不同的工具。 在大多数情况下，在此工具系列中定义一组铺面路径最为有效，并且提高了灵活性。

当你开始转向产品思维模式时，可以将这些铺平路径中的工程系统视为由工具组成，这些工具作为向开发团队提供服务进行集中管理。 然后，组织内的单个团队或部门可能会发生偏差，但需要单独管理、维护和支付其工具费用，同时仍遵守任何合规性要求。 这提供了一种在不中断的情况下将新工具馈送到生态系统中的方法，因为你可以评估随时间推移可能包含在铺面路径中的任何内容。 正如一位平台工程主管所说：

你仍然可以做自己的事， 但按照我们要的方向做... 你可以更改任何你想要的，但这将成为你的责任。 你拥有更改 - 你拥有锋利的刀。 - Mark，平台工程主管，大型欧洲跨国零售公司

鉴于平台工程的关键目标是转向向内部客户提供价值的产品思维模式，这种星座方法通常比自上而下的任务更有效。 在建立和优化铺路时，保留一些灵活性允许团队提供输入并解决给定应用程序的任何真正独特的要求，而不会影响组织中的其他人。 这会导致一组完全铺路的黄金路径，而其他路径只是部分铺路。 在没有独特要求的情况下，开发团队承担的额外工作自然会导致他们希望随着时间的推移而迁移到受支持的路径。

如果你更喜欢合并策略，请记住，迁移现有应用程序可能比预期的工作要多，因此，一开始，你可能希望专注于此空间的正确起点，并专注于新项目。 这为你提供了第一条铺路，而现有的所有内容本质上都是未铺平的。 然后，在新的铺面路径向组织显示其价值后，未铺就路径上的开发团队将考虑迁移。 此时，你可以开展一个正确的活动，通过双向沟通让每个人都处于你所需的状态，因为开发团队将此视为一种好处，而不是一种税收。 在活动期间，平台工程团队可以专注于帮助团队迁移，而开发团队则提供有关如何改进铺路的反馈。

无论如何，尽量避免使用铺面路径。 推出它们的最有效方法是强调团队从中获取哪些内容，而不是通过强制采用。 由于内部开发人员平台专注于让这些完全相同的团队感到高兴，因此，对个别领导者的预算和价值实现时间压力往往会照顾其余部分。 然后，获得正确的市场活动，为那些在未修补的道路上切换的最佳方式的双向对话提供了一个途径。

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

创建第一条铺平道路的一部分应该是建立核心开发人员自动化产品。 当你开始考虑启用开发人员自助服务功能时，这些都很重要。

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

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

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

例如，假设这些插图显示了两种使用GitHub Actions更新基础结构并部署到Azure Kubernetes 服务的方法：一种使用基于推送的部署，一种使用基于拉取 (GitOps) 部署。

若要详细了解每种方法，请参阅使用 GitHub Actions 和 Gitflow 的 AKS 应用的 CI/CD。

你选择的通常由现有的 IaC 技能集和目标 应用程序平台的详细信息驱动。 GitOps 方法是最新的，在使用 Kubernetes 作为其应用程序基础的组织中很受欢迎，而基于拉取的模型目前提供了最大的灵活性，因为它的可用选项数量。 我们预计大多数组织会混合使用这两者。 无论如何，精通 IaC 实践将有助于了解适用于进一步自动化方案的模式。

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

若要跨应用程序管理和缩放 IaC，应集中发布 IaC 项目以供重复使用。 例如，可以使用存储在云原生 OCI Artifact注册表（如 Azure 容器注册表 (ACR) 、DockerHub 或 Azure 部署环境中的目录） (ADE) 的注册表、Bicep 模块、Radius 食谱或 Helm 图表中的 Terraform 模块。 对于 GitOps 和 Kubernetes， 群集 API (和实现（如 CAPZ) ）可以让你管理 Kubernetes 工作负载群集，而自定义资源定义（如 Azure 服务操作员 ）可以为其他类型的 Azure 资源、跨多个云的其他工具（如 Crossplane 支持资源）提供额外的支持。 借助这些图表，可以在 ACR 等内容中使用集中式或通用 Helm 图表，以用于更广泛的方案。

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

选择哪种 IaC 格式取决于现有技能集、所需的控制级别以及使用的应用模型。 例如 ，Azure 容器应用 (ACA) 和最近的实验 性 Radius OSS 孵化项目比直接使用 Kubernetes 更引人注目，但也简化了开发人员体验。 描述云服务类型培训模块可帮助你了解不同模型的优缺点。 无论如何，引用集中式和托管的 IaC 而不是在源树中具有完整定义具有显著优势。

以开发人员无法直接访问基本构建基块中的层进行治理的方式保留任何所需的预配标识或机密。 例如，请考虑使用 Azure 部署环境 (ADE) 实现的角色分离的此图。

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

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

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

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

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

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

将频繁、高工作量或容易出错的流程确定为首先自动执行的潜在目标。 接下来，我们将介绍实现此目的的几种简单方法。

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

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

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

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

虽然 IaC 在帮助自动交付应用程序方面越来越受欢迎，但该模式可扩展到你可能想要预配和配置的任何基础结构、工具或服务，而不仅仅是那些绑定到特定应用程序的基础结构、工具或服务。 例如，通过安装了 Flux 的群集共享 K8，预配多个团队和应用程序使用的 DataDog 等内容，甚至设置你喜欢的协作工具。

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

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

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

由于创建 PR 的人员无法直接访问这些机密，因此它为开发人员提供了一种安全启动操作的方法，而他们没有直接权限自行执行的操作。 这允许你遵守最低特权原则，同时仍为开发人员提供自助服务选项。

跟踪预配的基础结构

开始缩放此方法时，请考虑要如何跟踪预配的基础结构。 git 存储库是配置的真实来源，但不会告诉你有关所创建内容的特定 URI 和状态信息。 但是，遵循一切即代码方法可提供一个信息源，以便综合预配的基础结构清单。 预配器也可能是此信息的良好来源，你可以利用这些信息。 例如，Azure 部署环境包括开发人员可了解的环境跟踪功能。

若要详细了解如何跨各种数据源进行跟踪，请参阅 设计开发人员自助服务基础。

将安全性应用为代码，将策略应用为代码模式

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

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

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

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

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

Teams 即代码

将所有内容作为代码应用于你自己的方案的一个示例是团队即代码模式。 组织应用此模式来标准化团队成员身份，在某些情况下，还可以跨各种系统实现开发人员工具/服务权利。 此模式消除了由系统开发人员和操作员访问其自己的分组、用户和访问概念而引起的手动加入和卸载服务台流程。 手动服务台进程存在潜在的安全风险，因为可能会过度预配访问权限。 将团队用作代码模式时，git 和拉取请求的组合可以从可审核的数据源启用自助服务。

有关此模式的成熟、广泛变体的示例，检查 GitHub 关于它们如何管理权利的博客文章。 GitHub 还开放了其复杂 权利实现的 源代码，供你试用或采用。 尽管博客文章介绍了所有员工权利，但你可以将团队作为代码概念应用于范围更窄的开发团队方案。 这些开发团队可能根本不在员工组织结构图中表示，并且涉及可能使加入或离职团队成员复杂化的专有工具或服务。

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

对于此示例，我们假设：

1. 所涉及的每个系统都已设置为使用标识提供者 (例如，Microsoft Entra ID) 进行单一登录 (SSO) 。
2. 你将使用标识提供者组 (例如，跨系统) Entra 组按角色管理成员身份，以降低复杂性并维护集中式审核。

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

1. 一个锁定的中央 git 存储库具有一组 (通常为 YAML) 文件，其中表示每个抽象团队、相关用户成员身份和用户角色。 团队更改的所有者/审批者也可以存储在同一位置， (例如，通过 CODEOWNERS) 。 这些文件中对用户的引用是标识提供者，但此存储库充当这些团队 (而不是) 用户的真实来源。
2. 与代码用例的其他所有内容一样，这些文件的所有更新都是通过拉取请求完成的。 这会将会话以及请求 git 提交的相关参与者关联到可审核性。
3. 潜在顾客和单个用户可以创建 PR 来添加/删除人员，开发线索和其他角色可以使用包含模板中新团队文件的 PR 创建新团队。
4. 每当 PR 合并到main时，绑定到存储库的 CI/CD 系统都会根据需要更新标识提供者系统和所有下游系统。

具体而言，CI/CD 系统：

5. 使用适当的标识提供者系统 API 创建或更新每个角色的标识提供者组，其中恰好是文件中的个人 (，不少于) 。
6. 为每个下游系统使用 API 将这些系统分组概念绑定到标识每个角色的提供程序组 (示例： GitHub 和 Azure DevOps) 。 这可能会导致团队与下游系统之间出现一对多关系来表示角色。
7. （可选）为每个下游系统使用 API 来实现绑定到系统分组机制的权限逻辑。
8. 使用 API 更新锁定的数据存储，其中包含结果 (包括关联下游系统团队 ID) ，这些 ID 随后可用于任何内部生成的系统。 如果需要，还可以在此处存储同一标识提供者用户/帐户的用户 ID 的不同系统表示形式的关联。

请注意，如果组织已在使用 类似于 Entra 权利管理的内容，则可以省略此模式中的组成员身份管理。

你的需求和策略可能会更改具体细节，但常规模式可以适应任意数量的变体。 与任何下游系统集成所需的任何机密都保留在 CI/CD 系统中 (例如，在 GitHub Actions、Azure Pipelines) 或 Azure 密钥保管库 中维护。

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

你确定的某些与自助服务相关的问题可能不利于使用 Git 中的文件。 或者，你可能想要使用用户界面来驱动自助服务体验。

幸运的是，大多数 CI 系统（包括 GitHub Actions 和 Azure Pipelines）都能够使用输入设置工作流，然后可以通过 UI 或 CLI 手动触发这些输入。 鉴于开发人员和相关操作角色可能已经熟悉这些用户体验，手动触发器可以增强所有内容作为代码模式，以启用活动 (或作业) 的自动化，这些活动或作业) 要么没有自然文件表示形式，要么应该完全自动化，而无需 PR 过程。

事实上，CI 系统可能允许你选择通过 API 从自己的用户体验触发这些工作流/管道。 对于GitHub Actions，执行此操作的关键是操作 REST API 触发工作流调度事件以触发工作流运行。 Azure DevOps 触发器 类似，还可以使用 Azure DevOps Pipeline 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 或想要执行完整的工作站虚拟化 (客户端工具和主机 OS 设置，以及项目特定的设置) ，VM 通常提供最佳功能。 从 Windows 客户端开发到 Windows 服务或管理和维护 .NET 完整框架 Web 应用程序，这些环境都很有用。

方法	示例
使用云托管的 VM	Microsoft Dev Box 是一个完整的 Windows 工作站虚拟化选项，内置了与桌面管理软件的集成。
使用本地 VM	Hashicorp Vagrant 是一个不错的选择，可以使用 HashiCorp Packer 为其和 Dev Box 生成 VM 映像。

工作区虚拟化和面向 Linux

如果面向 Linux，请考虑使用工作区虚拟化选项。 这些选项不太关注更换开发人员桌面，而更侧重于项目或应用程序特定的工作区。

方法	示例
使用云托管容器	GitHub Codespaces 是一个基于云的开发容器环境，支持与 VS Code、JetBrains 的 IntelliJ 和基于终端的工具集成。 如果此或类似服务不能满足你的需求，则可以将 VS Code 的 SSH 或 远程隧道 支持与远程 Linux VM 上的开发容器配合使用。 基于隧道的选项，它不仅适用于客户端，还适用于基于 Web 的 vscode.dev。
使用本地容器	如果你希望使用本地开发容器选项，或者除了云托管选项之外， 开发容器 在 VS Code 中提供可靠的支持、 IntelliJ中的支持以及其他工具和服务。
使用云托管的 VM	如果发现容器太有限制， VS Code 等工具或 JetBrains 工具（如 IntelliJ）中的 SSH 支持使你能够直接连接到自己管理的 Linux VM。 VS Code 具有 基于隧道的选项 在这里也有效。
使用适用于 Linux 的 Windows 子系统	如果开发人员仅使用 Windows，适用于 Linux 的 Windows 子系统 (WSL) 是开发人员在本地面向 Linux 的好方法。 可以为团队导出 WSL 分发，并将其与设置的所有内容共享。 对于云选项，Microsoft Dev Box 等云工作站服务还可以利用 WSL 来面向 Linux 开发。

创建包含“保持正确配置”的“开始”正确的应用程序模板

代码模式的一切的伟大之处在于，它可以使开发人员保持从一开始就建立的铺就路径。 如果这是组织的一个挑战，应用程序模板可以快速成为重用构建基块以推动一致性、促进标准化和编纂组织的最佳做法的关键方法。

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

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

保持正确和正确

但是，为了帮助缩放，这些应用程序模板应尽可能引用集中式构建基块， (例如 IaC 模板，甚至 CI/CD 工作流/管道) 。 事实上，你可能会发现，将这些集中式构建基块视为其自己的开始正确模板形式是解决已确定的一些问题的有效策略。

其中每个模板不仅可以应用于新应用程序，还可以应用于你打算更新的现有应用程序，作为推出更新或改进指南的正确活动一部分。 更好的是，这种集中化有助于使新应用程序和现有应用程序保持正确状态，从而随着时间推移而发展或扩展最佳做法。

模板内容

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

区域	详细信息
足够的示例源代码来驱动应用模式、SDK 和工具的使用	包括代码和配置，以引导开发人员使用建议的语言、应用模型和服务、API、SDK 和体系结构模式。 请务必使用所选工具包含分布式跟踪、日志记录和可观测性代码。
生成和部署脚本	为开发人员提供触发生成和本地/沙盒部署的常用方法。 包括 IDE/编辑器中的调试配置，以便选择使用它们的工具。 这是避免维护问题并防止 CI/CD 不同步的重要方法。如果模板化引擎的评价类似于Azure Developer CLI，则可能已有命令可以使用。
CI/CD 的配置	根据建议提供用于生成和部署应用程序的工作流/管道。 利用集中式、 可重用 或 模板化的 工作流/管道，帮助它们保持最新。 事实上，这些可重用的工作流/管道可以自行启动正确的模板。 请务必考虑手动触发这些工作流的选项。
基础结构即代码资产	提供建议的 IaC 配置，包括对 集中管理的模块或目录项 的引用，以确保任何基础结构设置都遵循获取的最佳做法。 这些参考还可以帮助团队随着时间的流逝而保持正确。 与工作流/管道结合使用，还可以包括 IaC 或 EaC 来 预配任何内容。
安全性和策略即代码资产	DevSecOps 移动还已将安全配置移动到代码中，这非常适合模板。 某些策略作为代码项目也可以在应用程序级别应用。 将 作为所有内容包含在 GitHub Advanced Security 中，从 CODEOWNERS 等文件到扫描配置（如 dependabot.yaml）。 使用 Defender for Cloud 之类的内容为扫描提供计划工作流/管道运行以及环境测试运行。 这对于供应链安全性尤其重要，除了应用程序包和代码外，还必须 考虑容器映像 。 这些步骤可帮助开发团队保持正确。
可观测性、监视和日志记录	启用自助服务的一部分是在部署后提供对应用程序的轻松可见性。 除了运行时基础结构之外，请确保包括用于可观测性和监视的设置。 在大多数情况下，设置 (有一个 IaC 方面，例如，代理部署、检测) ，而在另一些方面，它可能是另一种类型的配置为代码项目 (例如，监视 Azure 应用程序 Insights 的仪表板) 。 最后，请务必使用所选工具包含用于分布式跟踪、日志记录和可观测性的代码示例代码。
编码环境设置	包括用于编码 linters、格式化程序、编辑器和 IDE 的配置文件。 包括设置脚本以及工作区或工作站虚拟化文件，如 devcontainer.json、 devbox.yaml、开发人员重点 Dockerfiles、Docker Compose 文件或 Vagrantfiles。
测试配置	使用首选服务（如 UI Microsoft Playwright Testing 或 Azure 负载测试）为单元和更深入的测试提供配置文件。
协作工具设置	如果问题管理和源代码管理系统支持任务/问题/PR 模板作为代码，则还包括这些模板。 如果需要进行更多设置，可以选择提供使用可用 CLI 或 API 更新系统的工作流/管道。 这还允许你设置其他协作工具，如 Microsoft Teams 或 Slack。

优化应用程序平台