应用软件工程系统

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

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

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

评估基本 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 食谱或存储在云本机 OCI Artifact 注册表中的 Helm 图表（如 Azure 容器注册表（ACR）、DockerHub 或 Azure 部署环境（ADE）中的目录中使用 Terraform 模块。 对于 GitOps 和 Kubernetes，群集 API（和 CAPZ 等实现）可以让你管理 Kubernetes 工作负荷群集，而 Azure 服务操作员等自定义资源定义可以增加对其他类型的 Azure 资源的支持，其他工具（例如跨多个云支持资源）。 通过这些方法，你可以在类似 ACR 之类的内容中使用集中式或常见的 Helm 图表，以实现更广泛的方案。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

尽管 IaC 获得了帮助自动执行应用程序交付的流行性，但模式扩展到你可能想要预配和配置的任何基础结构、工具或服务，而不仅仅是那些绑定到特定应用程序的基础结构、工具或服务。 例如，与安装了 Flux 的群集共享 K8、预配多个团队和应用程序使用的 DataDog 等内容，甚至设置你喜欢的协作工具。

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

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

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

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

跟踪预配的基础结构

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

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

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

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

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

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

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

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

Teams 即代码

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

有关此模式的成熟、广泛变体的示例，请查看 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 随后可用于任何内部生成的系统。 如果需要，还可以存储同一标识提供者用户/帐户的不同系统 ID 表示形式的关联。

如果组织已在使用 Entra 权利管理等内容，则可能无法从此模式中省略管理组成员身份。

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

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

你确定的一些自助服务相关问题可能不利于在 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 或想要执行完整的工作站虚拟化（除了项目特定设置之外，客户端工具和主机 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 模板存储库一样简单的内容，但如果组织遵循 monorepo 模式，这可能不太有效。 还可以创建模板，帮助设置与应用程序源树不直接相关的内容。 相反，除了模板化和简化的 CI/CD 设置之外，还可以使用 cookiecutter、Yeoman 等模板化引擎，或者 Azure 开发人员 CLI（azd）提供一组方便的开发人员命令。 由于 Azure 开发人员 CLI 可用于在所有方案中驱动环境设置，因此它与 Azure 部署环境集成，以提供改进的安全性、集成的 IaC、环境跟踪、关注点分离和简化的 CD 设置。

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

保持正确和正确

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

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

模板内容

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

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

相关内容

• Microsoft的 DevOps 资源汇
• 容器供应链安全性
• 使用 GitHub Actions 和 Gitflow 的 AKS 应用的 CI/CD

优化应用程序平台