通过

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

  • 项目

本文介绍一个高级 DevOps 工作流，用于将应用程序更改部署到 Azure 中的过渡环境和生产环境。 该解决方案将持续集成/持续部署（CI/CD）做法与 Azure Pipelines 配合使用。

重要

本文介绍使用 Azure Pipelines 的一般 CI/CD 体系结构。 它不旨在涵盖部署到不同环境（例如 Azure 应用服务、虚拟机和 Azure Power Platform）的具体内容。 单独的文章介绍了部署平台细节。

建筑

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

下载该架构的 Visio 文件。

注意

尽管本文涵盖的是应用程序更改的 CI/CD，Azure Pipelines 也可用于构建基础设施即代码（IaC）更改的 CI/CD 流水线。

数据流

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

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

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

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

  2. CI 管道 - 与 Azure Repos Git 的合并会触发 CI 管道。 此管道运行的检查与 PR 管道相同，并增加一些重要内容。 CI 管道会运行集成测试。 集成测试可能占用大量资源，因此在 CI 管道中运行集成测试可以平衡开发速度和 bug 检测。 此外，请务必注意，在 PR 中通过测试并不总能确保合并后会成功，因为主分支中的更改可能会引入新问题，这突显了进行合并后测试的必要性。 这些因素使 CI 管道比 PR 管道更适合集成测试。 这些集成测试不应要求部署解决方案，因为尚未创建生成项目。 如果集成测试需要机密，管道将从 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 提供了生成、测试、打包和发布应用程序和基础结构代码的方法。 此示例有三个不同的管道，具有以下职责：

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

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

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

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

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

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

替代方案

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

  • Azure DevOps 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 组件和服务。

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

  • Azure Functions 是可用于生成应用程序的无服务器计算平台。 借助 Functions，可以使用触发器和绑定来集成服务。 Functions 也支持过渡和生产环境等部署槽。 可以将应用程序部署到过渡槽，并将其释放到生产槽。

  • Azure Kubernetes 服务（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 Well-Architected 框架的支柱，这是一组指导原则，可用于提高工作负荷的质量。 有关详细信息，请参阅 Microsoft Azure Well-Architected Framework。

卓越运营

  • 请考虑实现 基础结构即代码（IaC），以定义基础结构并将其部署到管道中。

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

  • 在发布定义中使用 发布变量 来驱动环境的配置更改。 发布变量的范围可以限定为整个发布或给定环境。 对机密信息使用变量时，请确保选择挂锁图标。

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

  • 考虑尽早在发布管道中使用 Application Insights 和其他监视工具。 许多组织仅开始在其生产环境中进行监视。 通过监控其他环境，可以更早识别开发过程中的缺陷，并避免生产环境中的问题。

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

  • 建议使用 YAML 流水线 而非经典接口。 YAML 管道可以像对待其他代码一样处理。 例如，可以将 YAML 管道签入到源代码管理和版本控制中。

  • 请考虑使用 YAML 模板 来促进重复使用和简化管道。 例如，PR 和 CI 的流水线很相似。 单个参数化模板可用于这两个管道。

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

成本优化

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

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

此 定价计算器 提供与 20 个用户一起运行 Azure DevOps 的估计值。

Azure DevOps 按用户按月计费。 除了任何其他测试用户或用户基本许可证之外，还可能需要更多费用，具体取决于所需的并发管道。

安全

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

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

  • 考虑在 Azure Pipelines 中集成步骤来跟踪依赖项、管理许可、扫描漏洞以及使依赖项保持最新。

后续步骤

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