0Pricing
Azure Fundamentals · 课时

使用 Azure Pipelines 构建 CI 管道

定义在拉取请求上触发的 YAML 管道,运行单元测试并生成构建项目,然后在门户中查看测试结果和代码覆盖率。

使用 Azure Pipelines 构建 CI 管道 是 CoddyKit 上的免费 Azure Fundamentals 课时。 这是第 2 节课,共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 Azure Fundamentals 学习路径的一部分,你的进度在网页和 CoddyKit 应用中同步。 Azure Fundamentals 课程共包含 4 节课。

什么是持续集成

持续集成 (CI) 是一种经常将代码更改合并到共享分支中的实践,并且每次合并都会自动触发构建和测试运行。其目标是在集成失败演变成大规模且难以修复的问题之前,尽早发现它们。一个良好的 CI Pipeline 会构建代码、运行单元测试、衡量代码覆盖率、执行静态分析,并在几分钟内生成可部署的构建产物。Azure Pipelines 为这一实践提供自动化引擎。

YAML Pipeline 结构

Azure Pipelines CI Pipeline 定义在代码仓库根目录的 azure-pipelines.yml 文件中。YAML 文件会指定触发器(何时运行)、池(使用哪种 Agent 类型),以及由阶段、作业和步骤组成的层次结构。默认情况下,各阶段按顺序运行。阶段内的各作业默认并行运行。作业内的各步骤按顺序运行。这种结构可以让您精细控制 Pipeline 的执行流程。

# azure-pipelines.yml skeleton
trigger:
  branches:
    include:
    - main
    - 'feature/*'
  paths:
    exclude:
    - docs/**
    - '*.md'

pool:
  vmImage: ubuntu-latest

variables:
  buildConfiguration: Release
  nodeVersion: '18.x'

stages:
- stage: CI
  displayName: 'Build and Test'
  jobs:
  - job: Build
    displayName: 'Build Application'
    steps: []

触发器配置

Azure Pipelines 支持多种触发器类型。分支触发器会在代码推送到指定分支时运行 Pipeline。拉取请求触发器(PR 触发器)会在针对目标分支创建或更新 PR 时运行,这对于在合并前验证代码至关重要。计划触发器会在固定时间运行(例如 Nightly 构建)。Pipeline 触发器可以将多个 Pipeline 串联起来。指定 trigger: none 可禁用自动运行,只允许手动执行。

# Branch trigger
trigger:
  branches:
    include: [main, develop]

# Pull request trigger
pr:
  branches:
    include: [main]
  autoCancel: true  # Cancel previous runs when PR is updated

# Scheduled trigger (nightly build at 02:00 UTC)
schedules:
- cron: '0 2 * * *'
  displayName: 'Nightly Build'
  branches:
    include: [main]
  always: true  # Run even if no new commits

步骤:脚本和任务

Pipeline 步骤可以是脚本(bash 或 PowerShell 命令),也可以是任务(来自 Azure DevOps marketplace 的预构建参数化单元)。NodeTool@0、DotNetCoreCLI@2 和 Maven@3 等任务封装了常见的构建操作。请在每个步骤中使用 displayName,以便 Pipeline 日志易于阅读。每个步骤都会按顺序运行;如果任何步骤以非零代码退出,Pipeline 就会失败,除非您设置 continueOnError: true。

steps:
- task: NodeTool@0
  displayName: 'Install Node.js 18'
  inputs:
    versionSpec: '18.x'

- script: npm ci
  displayName: 'Install dependencies (clean install)'

- script: npm run lint
  displayName: 'Run ESLint'

- script: npm run build
  displayName: 'Build production bundle'

- script: npm test -- --ci --coverage
  displayName: 'Run unit tests with coverage'

发布测试结果

运行测试后,请使用 PublishTestResults 任务将结果发布到 Azure DevOps。Azure Pipelines 会解析 JUnit、NUnit、XUnit 或 VSTest 结果文件,并在 Pipeline 运行界面中显示通过/失败数量、测试运行时长以及每项测试的详细信息。系统会持续跟踪测试历史记录,因此您可以发现不稳定的测试和回归问题。这对于整个团队了解代码质量至关重要。

# Example: Node.js project with Jest tests
steps:
- script: npm test -- --ci --reporters=jest-junit
  displayName: 'Run tests with JUnit reporter'
  env:
    JEST_JUNIT_OUTPUT_DIR: '$(Agent.TempDirectory)/test-results'

- task: PublishTestResults@2
  displayName: 'Publish test results'
  inputs:
    testResultsFormat: JUnit
    testResultsFiles: '$(Agent.TempDirectory)/test-results/**/*.xml'
  condition: succeededOrFailed()  # Publish even if tests fail

发布代码覆盖率

发布代码覆盖率报告,以便 Azure Pipelines 在 Pipeline 界面中显示覆盖率百分比和趋势。PublishCodeCoverageResults 任务接受 Cobertura 或 JaCoCo 格式的报告。请将其与分支覆盖率门禁结合使用——配置最低覆盖率阈值,并在覆盖率低于该阈值时使构建失败。覆盖率趋势有助于发现新增代码未配套相应测试的情况。

# Jest + coverage
- script: npm test -- --ci --coverage --coverageReporters=cobertura
  displayName: 'Run tests with coverage'

- task: PublishCodeCoverageResults@1
  displayName: 'Publish code coverage'
  inputs:
    codeCoverageTool: Cobertura
    summaryFileLocation: '$(System.DefaultWorkingDirectory)/coverage/cobertura-coverage.xml'
    reportDirectory: '$(System.DefaultWorkingDirectory)/coverage'

Pipeline 变量和变量组

将 Pipeline 配置存储在 YAML 中定义的变量内,这些变量可以位于 Pipeline、阶段或作业级别。对于敏感值(API 密钥、密码),请使用机密变量——在 Pipeline 库(UI)或变量组中设置它们,并在 YAML 中引用。变量组是可在多个 Pipeline 之间共享的可复用变量集合。将变量组链接到 Azure Key Vault,即可自动将 Key Vault 中的机密同步到 Pipeline 变量。

# Reference a variable group in a pipeline
variables:
- group: 'Production-Secrets'  # Linked to Azure Key Vault
- name: buildConfiguration
  value: Release

# Use a variable
steps:
- script: echo 'Building $(buildConfiguration) configuration'
- script: az webapp deploy --src-path drop.zip
  env:
    AZURE_SUBSCRIPTION_ID: $(AZURE_SUBSCRIPTION_ID)  # From Key Vault
    APP_API_KEY: $(APP_API_KEY)  # Secret, not printed in logs

构建产物:打包构建输出

成功构建后,请将输出打包为Pipeline 构建产物,以便下游阶段(例如部署阶段)访问它。使用 PublishPipelineArtifact 将文件从构建 Agent 上传到 Azure DevOps 构建产物存储中。在后续阶段或作业中,使用 DownloadPipelineArtifact 获取该构建产物。这样可以将构建作业与部署作业解耦,使它们能够在不同 Agent 或不同阶段中运行。

# Publish build artifact
- task: PublishPipelineArtifact@1
  displayName: 'Publish build artifact'
  inputs:
    targetPath: '$(System.DefaultWorkingDirectory)/dist'
    artifactName: webapp-drop
    publishLocation: pipeline

# In a later deployment job, download the artifact
- task: DownloadPipelineArtifact@2
  inputs:
    artifactName: webapp-drop
    targetPath: '$(Pipeline.Workspace)/drop'

- script: ls -la $(Pipeline.Workspace)/drop

使用并行作业加快构建

在一个阶段内定义多个作业,即可并行运行相互独立的任务。例如,可以同时运行单元测试和安全扫描,而不是按顺序运行。并行作业需要额外的构建分钟数,但可以大幅缩短 Pipeline 的总运行时长。使用 dependsOn 属性,可让一个作业在启动前等待一个或多个其他作业完成,从而在阶段内创建依赖关系图。

stages:
- stage: CI
  jobs:
  - job: UnitTests
    displayName: 'Run unit tests'
    steps:
    - script: npm test

  - job: LintAndSecurity
    displayName: 'Lint and security scan'
    steps:
    - script: npm run lint
    - script: npm audit --audit-level=high

  - job: BuildArtifact
    displayName: 'Build and publish artifact'
    dependsOn: [UnitTests, LintAndSecurity]
    condition: succeeded('UnitTests') and succeeded('LintAndSecurity')
    steps:
    - script: npm run build

使用分支策略进行构建验证

将 CI Pipeline 链接到 Azure Repos 中的分支策略,使其在针对 main 的拉取请求上自动运行,作为构建验证检查。只有 Pipeline 通过后才能合并。您可以组合多项检查:CI Pipeline 必须成功、至少 2 名审阅者必须批准、所有评论都必须解决,并且必须存在关联的工作项。这样就建立了质量门禁,可以阻止损坏的代码合并到主分支。

# Add build validation via CLI
az repos policy build create \
  --blocking true \
  --branch main \
  --branch-match-type exact \
  --build-definition-id <pipeline-id> \
  --display-name 'CI Build Validation' \
  --enabled true \
  --project MyProject \
  --repository-id <repo-id> \
  --queue-on-source-update-only true \
  --manual-queue-only false \
  --valid-duration 720  # Pipeline result expires after 12 hours

查看 Pipeline 运行结果

Pipeline 运行完成后,请在 Azure DevOps 门户中查看结果。Summary 选项卡显示总体通过/失败状态和耗时。Tests 选项卡列出所有测试结果,并支持按结果筛选。Code Coverage 选项卡显示覆盖率百分比,并突出显示未覆盖的代码行。点击任意作业即可查看逐步的日志输出。失败的 Pipeline 会以红色突出显示失败步骤,并提供完整的错误输出,便于快速诊断。

# View pipeline run results via CLI
az pipelines runs list \
  --pipeline-ids <pipeline-id> \
  --project MyProject \
  --query '[].{id:id, status:status, result:result, startTime:startTime}' \
  -o table

# View logs from a specific run
az pipelines runs logs list \
  --run-id <run-id> \
  --project MyProject

快速检查

请测试您对本课 Microsoft Azure Fundamentals (AZ-900) 概念的理解。

课程回顾

本课您学习了:Azure Pipelines YAML 使用阶段、作业和步骤定义 CI Pipeline,用于构建、测试和创建构建产物;PR 触发器和分支策略实施质量门禁,以阻止损坏的代码合并;PublishTestResults 和 PublishCodeCoverageResults 任务让整个团队都能了解测试质量。接下来,我们将学习如何持续部署到 Azure。

常见问题解答

「使用 Azure Pipelines 构建 CI 管道」课时是免费的吗?

是的 — 「使用 Azure Pipelines 构建 CI 管道」的完整文本可在网页上免费阅读。要进行交互式练习(内置代码编辑器和全天候 AI 导师)并解锁 Azure Fundamentals 课程的其余内容,请升级到 CoddyKit PRO。 Azure Fundamentals 课程共包含 4 节课。

「使用 Azure Pipelines 构建 CI 管道」这节课中我会学到什么?

定义在拉取请求上触发的 YAML 管道,运行单元测试并生成构建项目,然后在门户中查看测试结果和代码覆盖率。 你通过在浏览器中直接运行的动手代码来练习 Azure Fundamentals,全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 Azure Fundamentals 需要有经验吗?

无需任何先前经验。CoddyKit 上的 Azure Fundamentals 课程适合初学者到高级学习者,你可以从这里开始或从头开始,按照自己的节奏学习。 这是第 2 节课,共 4 节。

「使用 Azure Pipelines 构建 CI 管道」课时需要多长时间?

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动,所以你能稳步进步,并在网页和应用中从离开的地方继续。

我能在这节 Azure Fundamentals 课中编写并运行代码吗?

能。每节 Azure Fundamentals 课都包含内置代码编辑器,你可以在浏览器中直接编写并运行真实代码,并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

  1. Azure DevOps Services 概览
  2. 使用 Azure Pipelines 构建 CI 管道
  3. 持续部署到 Azure
  4. Azure 上的 GitHub Actions
← 返回 Azure Fundamentals