超级会员免费看
Azure DevOps 中的持续集成与部署：全面指南
在当今竞争激烈的科技环境中，企业需要不断采用新的实践和技术来保持领先地位。DevOps 就是这样一种方法，它强调开发和运营团队之间的协作，以更快地交付高质量的软件。本文将深入探讨 Azure DevOps 中持续集成（CI）和持续部署（CD）的相关内容，包括概念、配置方法以及架构分析。
1. CI 和 CD 概述
CI 和 CD 是软件开发中密切相关但又不同的实践。CI 是一种编程方法，要求开发人员在一天中多次将代码合并到共享存储库中。每次集成都会通过自动化构建和测试过程进行验证，以便尽快发现并修复任何问题。CD 则是将代码更改自动交付到生产环境的实践，它在 CI 的基础上增加了额外的测试和部署阶段。
1.1 CI 的关键要素
- 源代码控制 ：建立一个源代码控制系统，如 Git，用于存储代码库并管理代码更改。
- 自动化构建 ：设置一个自动化构建系统，如 Jenkins 或 Azure DevOps，与源代码控制系统集成，每当代码更改推送到存储库时就构建代码。
- 自动化测试 ：实施自动化测试，如单元测试、集成测试和功能测试，以验证代码更改并尽快发现问题。
- 集成 ：确保开发人员每天多次将他们的代码更改集成到共享存储库中。构建系统应在每次更改时自动运行测试并构建代码。
1.2 CD 的额外步骤
- 暂存环境 ：设置一个暂存环境，它是生产环境的副本，在代码更改向公众发布之前可以在其中进行部署和测试。
- 自动化部署 ：使用 Ansible 或 Terraform 等工具自动化部署过程，将代码更改从构建系统部署到暂存环境。
- 持续测试 ：持续运行测试，如集成测试、验收测试和性能测试，以验证代码更改是否按预期工作。
- 发布审批 ：建立一个发布审批流程，指定的人员或团队必须在代码更改部署到生产环境之前进行审查和批准。
- 持续监控 ：持续监控生产环境，以便尽快检测和解决任何问题。
2. Azure DevOps 中使用经典编辑器进行 CI 配置
在之前的配置中，我们将 Azure Repos 配置为项目的源代码控制，并配置了一些构建管道，但每个构建管道都需要手动运行。以下是使用经典编辑器配置 CI 的具体步骤：
2.1 配置触发条件
构建管道的顶部菜单中有多个选项，如任务、变量、触发器、选项和历史记录。在“触发器”部分，可以配置多种触发方式：
-
CI 触发
：当代码更改推送到源代码控制存储库时自动触发。
-
计划触发
：可以安排构建管道在指定的时间和日期运行。
-
拉取请求触发
：每当在源代码控制存储库中提出拉取请求时运行构建管道。
-
路径过滤器触发
：指定源代码控制存储库中会触发构建管道的路径。
-
YAML 管道触发
：使用源代码控制存储库中的 YAML 文件配置构建管道，并在 YAML 文件更改时自动运行管道。
-
工件触发
：每当从另一个管道发布工件时运行构建管道。
-
API 触发
：通过 REST API 调用触发构建管道。
-
门控签入触发
：类似于 CI 触发，但在触发构建之前需要手动批准，适用于在提交到源代码控制存储库之前必须审查的代码更改。
在管道配置中，进入“触发器”部分，选择“启用持续集成”选项，并将“分支规范”选项设置为“master”，然后保存更改。对所有构建管道执行相同的配置。
2.2 验证 CI 配置
完成上述配置后，我们可以对代码进行更改来验证 CI 配置是否正常工作。例如，修改虚拟网络的 Bicep 文件并更新 API 版本，然后提交更改。此时，每个管道的作业应该会被触发，几秒钟后，作业应该会完成。
以下是一个简单的 mermaid 流程图，展示了 CI 的基本流程：
graph LR
A[代码更改] --> B[推送到存储库]
B --> C{触发 CI 管道}
C -->|是| D[自动化构建]
D --> E[自动化测试]
E --> F{测试通过?}
F -->|是| G[代码集成]
F -->|否| H[修复问题]
H --> B
3. Azure DevOps 中的 CD 配置
为了持续提升客户体验，建立定期且完美的软件发布流程至关重要。CD 可以自动化从构建环境到生产环境的代码构建、测试、配置和部署过程。
3.1 持续部署触发
我们之前创建了一个发布管道来将代码部署到 Azure 环境。在发布管道中，每个工件的右上角有一个图标，选择该选项可以看到启用持续部署的控件。持续部署触发器允许在每次有新的构建工件可用时自动创建发布。可以使用“构建分支过滤器”为特定目标分支设置部署，只有当 Git 推送包含指定分支的更改时才会触发发布。
3.2 配置阶段和触发条件
回到发布管道，使用阶段下的“克隆”选项克隆现有的开发（Dev）阶段，并将其命名为生产（Prod）阶段。选择 Prod 阶段，可以看到预部署条件。阶段触发器允许为特定阶段设置触发部署的条件，可以通过选择“选择触发器”选项来设置。例如，可以选择在 Dev 阶段成功部署后触发发布，也可以选择仅手动触发。
在创建新发布时，可以定义其他配置，如将触发器从自动更改为手动、选择特定版本的工件以及提供发布描述。创建发布后，Dev 阶段将在几秒内完成，然后 Prod 阶段将自动开始。完成后，两个阶段都应处于成功状态。
以下是 CD 配置过程的步骤列表：
1. 进入发布管道，点击工件右上角图标启用持续部署。
2. 使用构建分支过滤器为特定分支设置部署。
3. 克隆 Dev 阶段并命名为 Prod 阶段。
4. 选择 Prod 阶段，设置预部署条件和阶段触发器。
5. 创建新发布，定义相关配置。
6. 等待 Dev 阶段和 Prod 阶段依次完成。
4. CI/CD 基线架构使用 Azure Pipelines
采用包含 CI 和 CD 的高级 DevOps 工作流，并结合 Azure Pipelines，对于任何寻求在 Azure 中高效可靠地部署应用程序的组织来说都是一个重大变革。
4.1 架构组件
- Azure Repos ：提供一套完整的版本控制工具，对于高效的代码管理至关重要。
- Azure Pipelines ：包括三个管道：
- 拉取请求构建验证管道 ：在合并前通过执行代码检查、构建和单元测试来验证代码。
- CI 管道 ：执行合并后验证，除了 PR 管道的检查外，还包括集成测试，并在成功时发布构建工件。
- CD 管道 ：处理工件部署、验收测试和生产发布。
- Azure Artifacts Feeds ：允许高效管理和共享软件包，如 Maven、npm、NuGet 等。
- Key Vault ：安全管理解决方案的敏感数据，如机密、加密密钥和证书。
4.2 数据流分析
- PR 管道 ：向 Azure Repos Git 提交拉取请求会触发 PR 管道，进行质量检查，包括构建代码、代码分析和单元测试。如果任何检查失败，管道结束，开发人员必须解决问题。如果所有检查通过，需要进行 PR 审查，审查通过后才能成功合并。
- CI 管道 ：代码合并到 Azure Repos Git 会触发 CI 管道，除了 PR 管道的检查外，还包括集成测试。如果需要，管道会从 Azure Key Vault 获取机密。成功运行后会创建并发布构建工件。
- CD 管道触发 ：构建工件的发布触发 CD 管道。
- CD 发布到暂存环境 ：CD 管道从 CI 管道下载构建工件并部署到暂存环境，运行验收测试。如果测试失败，管道结束，开发人员必须解决问题。成功测试后可能需要手动验证。
- CD 发布到生产环境 ：如果手动干预或未实施手动干预，管道将解决方案发布到生产环境，进行冒烟测试。如果手动干预导致取消、发布失败或冒烟测试失败，管道将启动回滚，开发人员必须进行必要的更改。
以下是 CI/CD 架构数据流的表格总结：
| 管道名称 | 触发条件 | 主要操作 | 结果 |
| ---- | ---- | ---- | ---- |
| PR 管道 | 拉取请求 | 代码构建、分析、单元测试、PR 审查 | 成功合并或解决问题 |
| CI 管道 | 代码合并 | 代码构建、分析、单元测试、集成测试、获取机密、发布工件 | 创建并发布构建工件 |
| CD 管道 | 工件发布 | 下载工件、部署到暂存环境、验收测试 | 发布到生产或解决问题 |
| CD 发布到生产 | 暂存环境测试通过 | 部署到生产环境、冒烟测试 | 成功发布或回滚 |
通过以上内容，我们详细了解了 Azure DevOps 中 CI 和 CD 的概念、配置方法以及基线架构。利用这些实践和工具，企业可以提高软件开发的可靠性和效率，更快地将新功能交付给客户。
接下来，我们将继续介绍如何构建一个多阶段的 YAML 管道，进一步优化 CI/CD 过程。
5. 构建多阶段 YAML 管道
考虑 SpringToys 希望使用 YAML 构建和发布管道来部署其核心应用程序的场景。使用 YAML 可以让用户获得与可视化设计器相同的管道功能，同时还能将标记文件像其他源文件一样进行管理。
5.1 配置新项目
要配置一个新的项目，可以按照以下步骤进行：
1. 在 Azure DevOps 中创建一个名为 SpringToysEShop 的新项目。
2. 从 https://github.com/MicrosoftLearning/eShopOnWeb.git 导入存储库。具体操作是，进入项目的左侧菜单，选择“Repos”，然后在“导入存储库”部分选择“导入”选项，提供存储库的 URL 并点击“导入”，几秒后导入过程应成功完成。
3. 创建一个 App Service。首先，访问 https://shell.azure.com 并确保选择 Bash 选项。使用以下命令创建一个新的资源组：
az group create --name 'SpringToys-RG' --location 'eastus'
- 使用以下命令创建一个 App Service 计划：
az appservice plan create --resource-group 'SpringToys-RG' --name SpringToysAppPlan --sku B3
- 最后，使用以下命令创建 App Service 实例：
az webapp create --resource-group 'SpringToys-RG' --plan 'SpringToysAppPlan' --name 'SpringToysEShop'
以下是配置新项目步骤的 mermaid 流程图：
graph LR
A[创建新项目 SpringToysEShop] --> B[导入存储库]
B --> C[访问 Azure Shell 选择 Bash]
C --> D[创建资源组]
D --> E[创建 App Service 计划]
E --> F[创建 App Service 实例]
5.2 配置 CI/CD 管道与 YAML
完成新项目配置后，接下来可以配置 CI/CD 管道。要添加 YAML 构建定义到项目中，需将相应文件包含在存储库的根目录。Azure DevOps 还为流行的项目类型提供默认模板和 YAML 设计器，可简化定义构建和发布任务的工作。
通过以上步骤，我们可以利用 YAML 构建一个多阶段的 CI/CD 管道，实现更高效的软件开发和部署流程。这种方法不仅提高了部署的可见性，还便于无缝集成审批和检查环节。
综上所述，Azure DevOps 提供了强大的工具和功能来支持 CI/CD 实践。从基本的 CI 和 CD 概念，到具体的配置方法，再到 CI/CD 基线架构的分析，以及多阶段 YAML 管道的构建，都为企业提供了全面的解决方案，帮助企业在软件开发和部署过程中提高效率、降低风险，并更快地将优质产品推向市场。
Azure DevOps 中的持续集成与部署：全面指南
6. 多阶段 YAML 管道的优势与实践
多阶段 YAML 管道在 Azure DevOps 的 CI/CD 流程中具有显著优势。它将 CI/CD 过程分解为不同阶段，代表了软件开发周期的各个阶段，增强了部署的可见性，便于集成审批和检查。
6.1 优势分析
- 提高可维护性 ：YAML 文件以文本形式存在，易于版本控制和团队协作。团队成员可以像管理代码一样管理管道配置，方便进行修改和审查。
- 增强灵活性 ：可以根据项目需求灵活定义多个阶段和任务，适应不同的开发场景。例如，可以为不同的环境（开发、测试、生产）设置不同的阶段和触发条件。
- 便于复用 ：YAML 管道中的任务和步骤可以被复用，减少了重复配置的工作量。例如，一些通用的构建和测试任务可以在多个管道中复用。
6.2 实践案例
以 SpringToys 为例，在完成新项目配置后，配置 CI/CD 管道的 YAML 文件如下：
# 定义管道的名称
name: SpringToysCI/CDPipeline
# 触发条件
trigger:
branches:
include:
- master
# 阶段定义
stages:
- stage: Build
displayName: Build Stage
jobs:
- job: BuildJob
displayName: Build Job
pool:
vmImage: 'ubuntu-latest'
steps:
- task: DotNetCoreCLI@2
displayName: Restore
inputs:
command: restore
projects: '**/*.csproj'
- task: DotNetCoreCLI@2
displayName: Build
inputs:
command: build
projects: '**/*.csproj'
arguments: '--configuration Release'
- task: DotNetCoreCLI@2
displayName: Test
inputs:
command: test
projects: '**/*Tests.csproj'
arguments: '--configuration Release'
- task: DotNetCoreCLI@2
displayName: Publish
inputs:
command: publish
projects: '**/*.csproj'
arguments: '--configuration Release --output $(Build.ArtifactStagingDirectory)'
- task: PublishBuildArtifacts@1
displayName: Publish Artifacts
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)'
ArtifactName: 'SpringToysApp'
publishLocation: 'Container'
- stage: DeployToStaging
displayName: Deploy to Staging
dependsOn: Build
condition: succeeded()
jobs:
- job: DeployToStagingJob
displayName: Deploy to Staging Job
pool:
vmImage: 'ubuntu-latest'
steps:
- task: DownloadBuildArtifacts@0
displayName: Download Artifacts
inputs:
buildType: 'current'
downloadType: 'single'
artifactName: 'SpringToysApp'
downloadPath: '$(System.ArtifactsDirectory)'
- task: AzureWebApp@1
displayName: Deploy to Staging App Service
inputs:
azureSubscription: '<Your Azure Subscription>'
appType: webApp
appName: 'SpringToysEShop-Staging'
package: '$(System.ArtifactsDirectory)/SpringToysApp/*.zip'
- stage: DeployToProduction
displayName: Deploy to Production
dependsOn: DeployToStaging
condition: succeeded()
jobs:
- job: DeployToProductionJob
displayName: Deploy to Production Job
pool:
vmImage: 'ubuntu-latest'
steps:
- task: DownloadBuildArtifacts@0
displayName: Download Artifacts
inputs:
buildType: 'current'
downloadType: 'single'
artifactName: 'SpringToysApp'
downloadPath: '$(System.ArtifactsDirectory)'
- task: AzureWebApp@1
displayName: Deploy to Production App Service
inputs:
azureSubscription: '<Your Azure Subscription>'
appType: webApp
appName: 'SpringToysEShop'
package: '$(System.ArtifactsDirectory)/SpringToysApp/*.zip'
上述 YAML 文件定义了一个包含三个阶段的 CI/CD 管道：
-
Build 阶段
：负责代码的恢复、构建、测试和发布，并将构建工件上传到 Azure Pipelines。
-
DeployToStaging 阶段
：从 Azure Pipelines 下载构建工件，并将其部署到暂存环境的 App Service。
-
DeployToProduction 阶段
：在暂存环境部署成功后，将构建工件部署到生产环境的 App Service。
7. 监控与优化 CI/CD 流程
为了确保 CI/CD 流程的稳定运行和持续优化，需要对其进行监控和分析。
7.1 监控指标
- 构建时间 ：记录每个构建阶段的开始时间、结束时间和持续时间，分析构建时间的变化趋势，找出可能存在的性能瓶颈。
- 测试通过率 ：统计自动化测试的通过率，及时发现代码中的问题。如果测试通过率下降，需要及时排查原因并进行修复。
- 部署成功率 ：记录每次部署的结果，统计部署成功率。如果部署成功率较低，需要检查部署过程中的配置和环境问题。
7.2 优化策略
- 并行执行任务 ：在 YAML 管道中，可以并行执行一些不相互依赖的任务，减少构建和部署时间。例如，在 Build 阶段，可以并行执行多个测试任务。
-
缓存依赖项
：对于一些频繁使用的依赖项，可以进行缓存，避免每次构建都重新下载。例如，在 DotNetCoreCLI 任务中，可以使用
cache任务来缓存 NuGet 包。 - 自动化故障处理 ：在 CI/CD 流程中，可以设置自动化故障处理机制，当出现问题时自动进行重试或回滚操作。例如，在部署任务中，可以设置重试次数和回滚条件。
以下是一个简单的 mermaid 流程图，展示了监控与优化 CI/CD 流程的基本步骤：
graph LR
A[开始 CI/CD 流程] --> B[监控指标]
B --> C{指标是否正常?}
C -->|是| D[继续流程]
C -->|否| E[分析问题]
E --> F[优化策略]
F --> G[实施优化]
G --> A
8. 总结与展望
通过本文的介绍，我们全面了解了 Azure DevOps 中 CI/CD 的相关内容，包括 CI 和 CD 的概念、配置方法、基线架构以及多阶段 YAML 管道的构建。利用这些实践和工具，企业可以实现高效、可靠的软件开发和部署流程，更快地将新功能交付给客户。
在未来，随着技术的不断发展，Azure DevOps 的 CI/CD 功能也将不断完善。例如，可能会引入更多的自动化工具和智能算法，进一步提高 CI/CD 流程的效率和可靠性。同时，与其他云服务和工具的集成也将更加紧密，为企业提供更全面的解决方案。
总之，掌握 Azure DevOps 中的 CI/CD 技术，对于企业在竞争激烈的市场中保持领先地位具有重要意义。企业应积极采用这些技术，不断优化软件开发和部署流程，以满足客户的需求。
扫一扫
1906
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
