手册

在合并拉取请求之前强制执行代码质量（构建、测试、覆盖率）。

→在目标分支上，配置一个构建验证策略，该策略在创建拉取请求时触发管道。管道必须发布代码覆盖率结果。设置一个分支策略以要求最低覆盖率。

原因: 这在合并前强制执行质量。标准的 CI 触发器在合并后运行。发布门控用于部署，而非拉取请求。

选择一种 Git 分支策略，最大限度地减少合并冲突并支持快速、持续部署到生产环境。

→实施基于主干的开发，使用短期功能分支，并频繁（每天或更频繁）合并到 `main`。

原因: 防止分支显著分歧，减少合并冲突，并确保 `main` 分支始终接近可发布状态。

通过在合并前强制执行代码审查、成功构建和工作项链接来保护关键分支（例如 `main`）。

→在 Azure Repos 的 `main` 分支上配置分支策略。启用最低审阅者、构建验证和工作项链接策略。

原因: 分支策略提供服务器端强制执行，开发人员无法绕过，从而确保一致的质量和流程合规性。

为具有预定发布、并行功能开发和需要专用热修复分支的团队选择一种 Git 分支策略。

→实施 GitFlow 分支模型，该模型使用 `main`、`develop`、`feature/*`、`release/*` 和 `hotfix/*` 分支。

原因: GitFlow 提供了一个强大的框架，用于管理复杂的发布周期，将新开发与发布稳定化和紧急修复隔离开来。

秘密意外提交并推送到仓库。它必须从所有 Git 历史记录中彻底删除。

→首先，轮换已泄露的秘密。然后，使用 `git-filter-repo` 或 BFG Repo-Cleaner 等工具重写历史记录，删除文件。强制推送更改并通知所有开发人员重新克隆。

原因: 简单的 `git rm` 或还原操作不会从历史记录中删除秘密。需要重写历史记录才能永久清除。

使用并行阶段和阶段间依赖关系来建模复杂工作流。

→使用 YAML 多阶段管道。使用 `dependsOn` 关键字定义阶段依赖关系，并在阶段内配置并行作业。

原因: YAML 为复杂编排提供了最灵活、基于代码的方法，优于经典管道或链接单独的管道。

为具有即时回滚能力的 Web 应用实施零停机、低风险部署。

→使用 Azure App Service 部署槽。部署到暂存（绿色）槽，验证后与生产（蓝色）槽进行槽交换。

原因: 槽交换是一个原子性的、近乎即时的操作，用于重定向流量。回滚就像交换回来一样简单。

参考↗

对于共享通用构建/部署步骤但需要特定自定义的众多微服务，最大限度地减少管道重复。

→在中央存储库中创建 YAML 模板。在每个特定服务的管道中，使用 `extends` 关键字并传递参数进行自定义。

原因: `extends` 推广 DRY 原则并强制执行标准，同时通过参数提供灵活性。对于整个管道结构，它比任务组更强大。

限制管道阶段（例如，生产部署）仅在合并到特定分支（例如，main）时运行。

→在阶段或作业上使用 `condition`。例如，`condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))`。

原因: 拉取请求验证构建使用不同的源分支引用（例如，`refs/pull/...`），因此此条件可正确防止在拉取请求生命周期内进行部署。

将应用程序从 Azure DevOps 部署到公司防火墙后的本地服务器。

→在本地服务器上安装自托管代理。将它们注册到 Azure DevOps 中的代理池。

原因: 自托管代理会主动向 Azure DevOps 发起出站通信，因此无需入站防火墙规则。它们可以访问本地网络资源进行部署。

要求多人审批生产部署，并将其限制在特定的维护窗口内。

→为生产环境定义一个 Azure DevOps 环境。配置包含所需审批者的审批。添加“工作时间”检查作为门控以强制执行时间窗口。

原因: 环境集中了部署控制。审批和门控在阶段运行前提供强大、自动化的策略执行。

无需重新部署应用程序即可控制用户功能曝光，并支持近实时更新。

→使用 Azure App Configuration 进行功能管理。检测应用程序以读取标志并启用其动态刷新功能。

原因: 将功能发布与部署解耦。App Configuration 提供集中式 UI 和 SDK 以进行动态更新，避免应用程序重启。

声明性地管理 Kubernetes 集群状态，其中 Git 是唯一的真相来源，并且更改会自动应用。

→将 Flux 或 ArgoCD 等 GitOps 代理部署到 AKS 集群。配置代理以监控包含 Kubernetes manifests 的 Git 存储库，并自动同步集群状态。

原因: 这种基于拉取的模型实现了持续协调和漂移检测，这是 GitOps 的核心。它比基于推送的 `kubectl` 管道更健壮。

管理用于团队协作的 Terraform 状态，确保安全性并防止并发修改。

→配置 Terraform 后端以使用 Azure 存储帐户。这提供了远程状态存储，并通过 Azure Blob 租约处理状态锁定。

原因: 防止同时 `apply` 操作导致状态文件损坏，并将敏感状态数据排除在源代码管理之外。

参考↗

在单体仓库中，仅当特定目录（或共享目录）中的文件发生更改时才触发应用程序的 CI 管道。

→在管道的 YAML 中，使用 `trigger.paths.include` 过滤器来指定相关目录，例如 `include: ['/apps/frontend/**', '/apps/shared/**']`。

原因: 这避免了不相关的代码更改导致不必要的构建，从而节省了 CI 时间和计算资源。

优化包含快速（单元）和慢速（集成）测试的测试阶段，以获得更快的反馈。

→在同一阶段内，并行运行单元测试和集成测试。

原因: 并行执行可以更快地提供单元测试结果，同时运行较慢的测试。总阶段持续时间由最长的作业决定，而不是所有作业的总和。

根据提交历史自动版本化库包，以清晰地传达更改的影响（破坏性更改、功能、修复）。

→将 GitVersion 等工具集成到 CI 管道中。它分析提交消息、分支和标签以自动计算 SemVer（主版本.次版本.补丁版本）。

原因: SemVer 提供了有意义的版本控制，消费者可以依赖它进行依赖管理，这与构建号或提交哈希不同。

将应用程序逐个部署到多个地理区域，并在每个区域部署后进行验证。

→使用多阶段 YAML 管道，其中包含按顺序排列的阶段，每个区域一个阶段，使用 `dependsOn` 来强制执行顺序。在阶段之间使用环境门控进行验证。

原因: 这种基于环的部署模型将不良部署的影响范围限制在单个区域，允许在影响所有用户之前进行回滚。

配置管道以支持基于主干的开发模型，确保主分支始终可部署。

→在 `main` 分支上配置 CI 触发器。通过运行快速、全面测试的构建验证策略强制执行拉取请求。集成快速通知（例如，发送到 Teams/Slack）以报告构建中断。

原因: 即时反馈在基于主干的开发中至关重要。这种组合可以防止损坏的代码合并，并确保在出现问题时快速补救。

在管道阶段之间高效地传递大型工件（例如，ML 模型，大于 5GB）。

→在生产阶段将大型工件上传到 Azure Blob Storage。将 blob URI 作为输出变量传递给消费阶段。

原因: 对于多 GB 文件，Azure Blob Storage 比内置管道工件更具成本效益和性能。

通过避免在每次运行时重新下载依赖项（例如 NuGet、npm）来减少构建时间。

→使用 `Cache@2` 任务。根据包锁定文件（例如 `packages.lock.json`）定义一个键。该任务将存储和恢复依赖项文件夹。

原因: 通过从快速的本地缓存恢复而不是从外部仓库获取，每次构建可以节省几分钟。

并行地针对多个目标（例如，不同的操作系统、区域）构建或部署相同的代码。

→在 YAML 管道作业中使用 `strategy: matrix`。为每个组合定义变量，这将为每个矩阵条目生成一个作业。

原因: 矩阵策略保持管道定义 DRY，从单个定义创建多个作业变体并并行运行它们。

在 AKS 上实施金丝雀部署，根据实时指标自动切换流量并进行升级或回滚。

→使用渐进式交付控制器，例如 Flagger，并与服务网格（例如 Istio）和指标提供程序（例如 Prometheus）集成。

原因: Flagger 自动化了整个金丝雀分析过程，提供了比手动脚本更安全、更可靠的渐进式交付。

当代码在其自身的仓库或单独的共享库仓库中发生更改时，需要触发应用程序管道。

→在应用程序的 YAML 中，在 `resources.repositories` 下定义共享库，并配置该资源的 `trigger` 块。

原因: 在仓库之间创建声明性依赖关系，确保应用程序始终使用最新的共享组件进行重建。

管道需要创建临时基础设施进行测试，并确保即使测试失败也能在之后销毁它。

→使用多阶段管道，为 IaC (Terraform/Bicep) 分别设置应用和销毁阶段。将销毁阶段配置为 `condition: always()`。

原因: `always()` 条件保证清理阶段无论前一阶段成功或失败都会运行，从而防止遗留资源。

阻止生产部署继续进行，除非 ITSM 工具（如 ServiceNow）中存在已批准的变更请求。

→配置一个环境门控，该门控调用“查询 ServiceNow”门控以检查变更请求的状态。

原因: 自动化与企业变更管理流程的集成，确保合规性，无需手动交接。

提供一个自托管构建代理池，该代理池根据需求动态扩展，以减少排队时间和控制成本。

→使用 Azure 虚拟机规模集 (VMSS) 配置 Azure DevOps 代理池，并设置为根据待处理作业的数量自动扩展。

原因: VMSS 代理将自托管代理的自定义能力与云托管代理的弹性相结合，优化了性能和成本。

以防止数据丢失和支持回滚的方式部署数据库架构更改。

→使用迁移工具（例如 Flyway、DbUp）。对架构更改实施扩展/收缩模式以保持向后兼容性。

原因: 迁移工具提供版本控制。扩展/收缩模式将应用程序和数据库回滚解耦，从而实现更安全的部署。

自托管代理因累积的构建工件而磁盘空间不足。

→在管道 YAML 中，在作业级别配置 `workspace: clean: all`。

原因: 这种预防性的管道配置解决了根本原因，无需手动干预或持续的基础设施更改。

集成测试需要为每次管道运行提供一个独立的数据库实例。

→在管道 YAML 中，将容器资源（例如 SQL Server、Postgres）定义为服务。然后测试作业可以连接到此临时服务。

原因: 为测试提供快速、隔离且自动清理的依赖项，防止测试干扰并简化设置。

提高从公共仓库（例如 npmjs、nuget.org）恢复包的可靠性和性能。

→在 Azure Artifacts 中，创建一个源并配置指向公共仓库的上游源。让客户端从 Azure Artifacts 源消费包。

原因: 该源缓存来自上游源的包，可防止公共仓库中断，并加快常用包的恢复速度。

使用不同的配置值将 Helm chart 部署到多个环境（开发、生产）。

→为每个环境使用单独的 `values-<env>.yaml` 文件。在 `HelmDeploy` 任务中，使用 `valueFile` 输入指定相应文件，并使用 `overrideValues` 注入动态值，例如镜像标签。

原因: 这种模式将静态环境配置与动态管道变量分离，使部署保持整洁和可维护。

在管道中安全地管理和使用密钥（例如连接字符串），而无需对其进行硬编码。

→将密钥存储在 Azure Key Vault 中。在 Azure DevOps 中，创建一个链接到 Key Vault 的变量组。在管道中从变量组引用密钥。

原因: 通过 Key Vault 集中密钥管理，无需更改管道即可启用轮换，并提供强大的访问控制和审计功能。

在 CI 管道中实施安全扫描，以检测应用程序代码 (SAST) 和第三方依赖项 (SCA) 中的漏洞。

→集成 Microsoft Security DevOps 扩展，其中包含多个扫描器。还可以考虑适用于 Azure DevOps 的 GitHub Advanced Security 以获取原生、全面的套件。

原因: 这种“左移”方法在开发生命周期的早期识别漏洞，从而降低成本和风险。

限制开发人员对生产环境的访问，以防止直接更改，同时仍允许经过审计的紧急访问。

→删除永久性贡献者/所有者角色。使用管道服务连接进行部署。对于紧急情况，使用 Azure AD Privileged Identity Management (PIM) 进行即时 (JIT) 提升访问。

原因: PIM 提供有时限、经审批和全面审计的提升访问权限，遵守最小权限原则。

安全地向 AKS 中的微服务提供秘密，支持自动轮换和特定于工作负载的访问。

→使用 Azure Key Vault 集成 AKS 的 Secrets Store CSI 驱动程序。使用工作负载身份让 Pod 认证到 Key Vault。

原因: 将秘密直接从 Key Vault 挂载到 Pod 中，避免使用 Kubernetes Secrets。实现 Pod 级别的身份识别和无缝秘密轮换。

参考↗

强制只允许将经过扫描和签名的容器镜像部署到生产 Kubernetes 集群。

→使用 Azure Container Registry (ACR) 内容信任进行镜像签名。使用 Microsoft Defender for Containers 进行扫描。使用 Azure Policy for Kubernetes 在 AKS 上强制执行策略。

原因: 为容器镜像安全提供从构建到运行时的全面、策略驱动的深度防御策略。

在不使用客户端秘密或证书的情况下，将 Azure Pipelines 连接到 Azure 资源。

→使用“工作负载身份联合”创建 Azure 资源管理器服务连接。

原因: 消除了管理和轮换秘密的需要，提高了 CI/CD 系统的安全态势。

在不交换秘密的情况下，从您的 Azure DevOps 组织部署到客户的 Azure 订阅。

→在客户的 Azure 环境中部署自托管代理。为代理的 VM/VMSS 分配托管身份，并授予其必要的 RBAC 角色。

原因: 将所有身份验证主体保留在客户租户内，遵循零信任模型。没有秘密跨越租户边界。

管理大型产品上多个团队的工作，允许团队自治，同时为领导层提供跨团队可见性。

→使用一个带有“区域路径”的单一项目，为每个团队提供过滤后的待办事项。使用“交付计划”来可视化跨团队的进度和依赖关系。

原因: 支持汇总报告和依赖项跟踪，同时允许每个团队独立管理自己的冲刺和工作项。

自动将提交/拉取请求链接到工作项，并在拉取请求合并时将工作项的状态（例如，更改为“已解决”）进行转换。

→在项目设置中，启用“通过拉取请求自动完成工作项”。开发人员必须在提交消息中使用 `#<ID>` 或链接拉取请求。

原因: 减少开发人员的手动工作量，保持工作项状态最新，并提高代码和需求之间的可追溯性。

衡量关键过程指标，如周期时间、交付周期和 DORA 指标，以进行价值流分析。

→使用 Azure DevOps Analytics 服务及其 OData 源。连接 Power BI 或使用内置仪表板小部件来可视化这些指标。

原因: Analytics 服务提供关键流和 SRE 指标的底层数据，从而实现数据驱动的流程改进。

调查被平均性能指标隐藏的间歇性慢响应时间。

→在 Application Insights 中，使用“性能”刀片进行百分位分析 (P95, P99) 和事务搜索，以深入研究特定的慢请求样本。

原因: 平均值可能具有误导性。百分位数揭示了性能问题的“长尾”，这些问题通常代表了最沮丧的用户。

跟踪单个用户请求在多个微服务之间的流转，以识别瓶颈或故障点。

→使用 Application Insights SDK 检测所有服务。它会自动在服务调用之间传播 W3C Trace Context 关联 ID。

原因: 在应用程序映射中提供分布式事务的统一视图，从而可以调试复杂的交互。

主动监控应用程序的服务级别目标 (SLO)，并在 SLO 被违反 *之前* 收到警报。

→在 Azure Monitor 中使用 KQL 查询定义 SLI。创建一个基于错误预算消耗率（预算消耗速度）触发的警报规则。

原因: 消耗率警报是预测性的，可以在 SLO 被违反且用户受到重大影响之前提供响应时间。

从用户的角度验证部署在功能上是成功的，而不仅仅是管道任务已完成。

→作为部署后步骤或发布门控，运行 Application Insights 可用性测试（合成监控），模拟关键用户流程。

原因: 管道成功仅表示数据已传输。合成测试确认应用程序实际正在工作，捕获错误配置或依赖项故障。

将部署事件与应用程序性能和错误率指标的变化进行可视化关联。

→使用 Azure Pipelines 任务在 Application Insights 中创建“发布注解”，它会在指标图表上放置一个标记。

原因: 提供即时视觉反馈，以快速识别最近的部署是否引入了性能退化或错误。

以受控方式主动测试应用程序和基础设施对故障的弹性。

→将 Azure Chaos Studio 集成到发布管道中。创建注入故障（例如，VM 关闭、网络延迟）并验证系统行为的实验。

原因: 超越对预期行为的测试，转向对意外故障的测试，从而建立对系统弹性的信心。