通过

使用 Azure Pipelines 的 CI/CD 基线体系结构

  • 项目

本文介绍用于将应用程序更改部署到 Azure 中的过渡环境和生产环境的概要 DevOps 工作流。 该解决方案通过 Azure Pipelines 使用持续集成/持续部署 (CI/CD) 做法。

重要

本文介绍使用 Azure Pipelines 的常规 CI/CD 体系结构。 它不涉及部署到不同环境（例如 Azure 应用服务、虚拟机和 Azure Power Platform）的具体内容。 部署平台的详细信息在单独的文章中介绍。

体系结构

使用 Azure Pipelines 的 CI/CD 管道的体系结构示意图。

下载此体系结构的 Visio 文件。

注意

虽然本文介绍的是通过 CI/CD 实现应用程序更改，但 Azure Pipelines 也可用于生成 CI/CD 管道以实现基础结构即代码 (IaC) 更改。

数据流

数据流经方案的情形如下所示：

  1. PR 管道 - 针对 Azure Repos Git 的拉取请求 (PR) 会触发 PR 管道。 此管道运行快速质量检查。 这些检查应该包括：

    • 生成需要从依赖项管理系统拉取依赖项的代码。
    • 使用工具来分析代码，例如静态代码分析、Lint 分析和安全扫描
    • 单元测试

    如果任何检查失败，管道运行将结束，开发人员必须进行所需的更改。 如果所有检查都通过，则管道应需要 PR 评审。 如果 PR 评审不通过，管道将结束，开发人员必须进行所需的更改。 如果所有检查和 PR 评审都通过，PR 将成功合并。

  2. CI 管道 - 针对 Azure Repos Git 的合并会触发 CI 管道。 此管道运行的检查与 PR 管道相同，并增加一些重要内容。 CI 管道会运行集成测试。 这些集成测试不应要求部署解决方案，因为尚未创建生成工件。 如果集成测试需要机密，则该管道会从 Azure Key Vault 获取这些机密。 如果任何检查失败，管道将结束，开发人员必须进行所需的更改。 成功运行此管道的结果是创建并发布生成工件

  3. CD 管道触发器 - 发布工件会触发 CD 管道。

  4. CD 发布到过渡环境 - CD 管道下载在 CI 管道中创建的生成工件，并将解决方案部署到过渡环境。 然后，管道针对过渡环境运行验收测试，以便验证部署。 如果有任何验收测试不通过，管道都将结束，开发人员必须进行所需的更改。 如果测试成功，则可以执行手动验证任务，要求个人或小组验证部署并继续管道。

  5. CD 发布到生产环境 - 如果手动干预已恢复，或者未实施手动干预，则管道会将解决方案发布到生产环境。 管道应在生产环境中运行冒烟测试，以确保发布按预期工作。 如果手动干预步骤导致取消、发布失败或冒烟测试失败，则发布将回滚，管道将结束，开发人员必须进行所需的更改。

  6. 监视 - Azure Monitor 收集可观测性数据（例如日志和指标），以便操作员可以分析运行状况、性能和使用情况数据。 Application Insights 收集所有特定于应用程序的监视数据，例如跟踪。 Azure Log Analytics 用于存储所有这些数据。

组件

  • Azure Repos Git 存储库充当代码存储库，为协作项目提供版本控制和平台。

  • Azure Pipelines 提供一种生成、测试、打包和发布应用程序及基础结构代码的方法。 此示例有 3 个不同管道，具有以下职责：

    • PR 管道会在允许 PR 通过 lint 分析、生成和单元测试合并前验证代码。
    • CI 管道在代码合并后运行。 它们执行与 PR 管道相同的验证，但如果一切成功，则添加集成测试并发布生成工件。
    • CD 管道部署生成工件、运行验收测试并发布到生产环境。

  • Azure 工件源让你可以管理和共享软件包，例如 Maven、npm 和 NuGet。 使用工件源可以管理包的生命周期，包括包的版本控制、升级和停用。 这有助于确保团队使用最新且最安全的包版本。

  • Key Vault 提供一种方法来管理解决方案的安全数据，包括机密、加密密钥和证书。 在此体系结构中，它用于存储应用程序机密。 这些机密通过管道访问。 Azure Pipelines 可以通过 Key Vault 任务或从 Key Vault 链接机密来访问机密。

  • Monitor 是一种收集并存储 Azure 服务的指标和日志、应用程序遥测和平台指标的可观测性资源。 使用此数据可以监视应用程序，设置警报、仪表板，以及针对故障执行根本原因分析。

  • Application Insights 是一种监视服务，可提供对 Web 应用程序的性能和使用情况的实时见解。

  • Log Analytics 工作区提供了一个中心位置，可在其中存储、查询和分析来自多个源（包括 Azure 资源、应用程序和服务）的数据。

备选方法

虽然本文重点介绍 Azure Pipelines，但不妨考虑以下替代方法：

  • Azure DevOps Server（以前称为 Team Foundation Server）可用作本地替代项。

  • Jenkins 是一种用于自动化生成和部署的开源工具。

  • GitHub Actions 让你可直接从 GitHub 自动执行 CI/CD 工作流。

  • GitHub 存储库可以替换为代码存储库。 Azure Pipelines 可与 GitHub 存储库无缝集成。

本文重点介绍 Azure Pipelines 的一般 CI/CD 做法。 下面是可以考虑部署到的一些计算环境：

  • 应用服务是一项基于 HTTP 的服务，用于托管 Web 应用程序、REST API 和移动后端。 可以使用自己喜欢的语言进行开发，应用程序可在基于 Windows 或 Linux 的环境中轻松地运行和缩放。 Web 应用支持过渡和生产等部署槽。 可以将应用程序部署到过渡槽，然后将其发布到生产槽。

  • Azure 虚拟机可以处理需要较高控制度，或者依赖于 Web 应用所不支持的 OS 组件和服务（例如 Windows GAC 或 COM）的工作负载。

  • Azure Power Platform 是一系列云服务的集合，用户无需基础结构或技术专业知识即可生成、部署和管理应用程序。

  • Azure Functions 是一个无服务器计算平台，可用于构建应用程序。 借助 Functions，可利用触发器和绑定集成服务。 Functions 也支持过渡和生产环境等部署槽。 可以将应用程序部署到过渡槽，然后将其发布到生产槽。

  • Azure Kubernetes Service (AKS) 是 Azure 中的托管 Kubernetes 群集。 Kubernetes 是开源容器业务流程平台。

  • Azure 容器应用让你可在无服务器平台上运行容器化应用程序。

方案详细信息

使用经过验证的 CI 和 CD 做法来部署应用程序或基础结构更改具有各种益处，包括：

  • 发布周期较短 - 自动化 CI/CD 过程让你的部署比手动实践更快。 许多组织每天部署多次。
  • 代码质量更好 - CI 管道中的质量入口（如 Lint 分析和单元测试）会产生更高质量的代码。
  • 发布风险降低 - 适当的 CI/CD 实践可大幅降低发布新功能的风险。 可以在发布之前测试部署。
  • 工作效率提高 - 自动化 CI/CD 可让开发人员无需进行手动集成和部署，从而可以专注于新功能。
  • 启用回滚 - 虽然适当的 CI/CD 实践可降低已发布 bug 或回归的数量，但它们仍会发生。 CI/CD 可以启用自动回滚到早期版本。

可能的用例

对于以下目的，请考虑使用 Azure Pipelines 和 CI/CD 过程：

  • 加速应用程序开发和部署生命周期。
  • 将质量和一致性管理内置到自动化的生成和发布过程中。
  • 提高应用程序稳定性和正常运行时间。

注意事项

这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改善工作负载质量的指导原则。 有关详细信息，请参阅 Microsoft Azure 架构良好的框架。

卓越运营

  • 请考虑实现基础结构即代码 (IaC) 来定义基础结构并将其部署到管道中。

  • 考虑使用 VSTS 市场上提供的令牌化任务之一，其上下文通常是指在部署或配置过程中用令牌或占位符替换敏感信息（如 API 密钥、密码或其他秘密）的过程。

  • 在发布定义中使用发布变量来驱动对环境的配置更改。 发布变量的作用域可以是整个发布，也可以是给定的环境。 将变量用于机密信息时，请确保选择挂锁图标。

  • 如果要部署到在受保护的虚拟网络中运行的资源，请考虑使用自托管代理。 如果运行大量生成，还可以考虑使用自托管代理。 在生成量较大的情况下，可以使用自托管代理以经济高效的方式加快生成速度。

  • 考虑尽早在发布管道中使用 Application Insights 和其他监视工具。 许多组织只在其生产环境中开始监视。 如果监视其他环境，则可以提前在开发过程中识别 Bug，避免生产环境中出现问题。

  • 请考虑对生产环境使用单独的监视资源。

  • 考虑使用 YAML 管道，而不是经典接口。 YAML 管道可像其他代码一样对待。 例如，可以将 YAML 管道签入到源代码管理和版本控制中。

  • 考虑使用 YAML 模板来促进重复使用和简化管道。 例如，PR 和 CI 管道类似。 单个参数化模板可用于这两种管道。

  • 请考虑创建过渡和生产环境以外的环境，以支持手动用户验收测试、性能和负载测试以及回滚等活动。

成本优化

成本优化是关于寻找减少不必要的费用和提高运营效率的方法。 有关详细信息，请参阅成本优化支柱概述。

Azure DevOps 成本取决于组织中需要访问权限的用户数和其他因素，例如，所需的并发生成/发布数，以及测试用户数。 有关详细信息，请参阅 Azure DevOps 定价。

此定价计算器提供 20 个用户运行 Azure DevOps 的估计费用。

Azure DevOps 按每月每个用户计费。 可能存在额外费用，具体取决于所需的并发管道数，以及是否有其他测试用户，或者是否使用了基本的用户许可证。

安全性

  • 在选择是使用 Microsoft 托管代理还是自托管代理时，请考虑使用 Microsoft 托管代理的安全优势。

  • 确保通过管道完成对环境的所有更改。 以最低特权原则实现基于角色的访问控制 (RBAC)，防止用户访问环境。

  • 请考虑在 Azure Pipelines 中集成步骤，以跟踪依赖项，管理许可，扫描漏洞并将依赖项保持为最新状态。

后续步骤

查看以下资源详细了解 CI/CD 和 Azure DevOps：