Azure Pipelines 教程：初学者完整 CI/CD 指南

如果您的 CI/CD 流水线总是出错，或者运行缓慢又笨拙，您并不孤单。我也经历过构建失败、环境不一致，以及队友不小心覆盖我工作的情况。Azure Pipelines 通过云托管服务帮您摆脱这些烦恼，它几乎可以在任何平台上构建、测试并部署任何项目。

因此，在本教程中，我将向您展示如何：

1. 创建您的第一个 Azure Pipeline
2. 在云端构建您的项目
3. 添加自动化测试，及早捕获错误
4. 一次推送即可部署到预发布或生产环境
5. 监控并优化流水线的速度与可靠性
6. 遵循在真实项目中验证过的最佳实践

让我们开始吧！

什么是 Azure Pipelines？

Azure Pipelines 是一项基于云的解决方案，可简化应用的开发、测试与部署。

它是 Azure DevOps 工具集的一个组件，覆盖整个软件开发生命周期。由于支持多种平台和编程语言，它对各类规模团队都十分灵活。它还能与 GitHub、Azure Repos 以及其他知名版本控制系统集成。

Azure Pipelines 的核心特性包括：

根据我的经验，Azure Pipelines 对任何想在团队内建立规范 CI/CD 的人都很有帮助。它灵活、可扩展，并能与其他 Azure 服务良好集成。

Azure Pipelines 架构（来源：Microsoft）。

如果您希望在流水线之外更广泛地了解 Azure DevOps， 这篇 Azure DevOps 教程讲解了从头到尾的整个 CI/CD 生命周期。

设置您的第一个 Azure Pipeline

要在 Azure Pipelines 环境中开展工作，我们首先需要进行端到端的构建、测试与部署流程的基础设置。

先决条件

在开始创建第一个流水线之前，请确保您具备以下条件：

1. Azure DevOps 账户与组织设置： 如尚无账户，请在Azure DevOps注册。创建一个组织用于管理您的项目。
2. 代码仓库： 您需要一个包含示例项目的代码仓库。它可以托管在 Azure Repos 或 GitHub。本教程将使用一个简单的 Node.js 项目。
3. Azure 门户访问权限： 当您希望部署到 Azure 服务（例如 Azure Kubernetes Service，AKS）等时，还需要访问Azure 门户。

如果您需要先熟悉更广泛的 Azure 生态，建议查看 Understanding Microsoft Azure 课程。

创建新项目与仓库

现在您的 Azure DevOps 账户与组织已设置完成，我们来创建第一个项目与仓库。

• 创建新项目：
  • 登录您的 Azure DevOps 账户。
  • 点击 New Project，为其命名（例如："AzureDevOps-DataCamp-Tutorial"），并选择可见性（公开或私有）。
  • 点击 Create Project。

• 设置仓库：
  • 如果使用 Azure Repos，前往 Repos区域并初始化新仓库。
  • 或者，您也可以选择 Import Repository来链接现有 GitHub 仓库。
  • 为仓库命名，选择 Repository type（Git 或 TFVC），粘贴克隆仓库的 URL，然后点击 Import。

• 如果您使用 GitHub，可以在项目界面左下角进入 Project Settings > GitHub Connections > Connect your GitHub account 来链接 GitHub 账户。

在本教程中，我们将使用 Azure Repos 作为代码仓库。如果您刚开始或没有特定理由选择 TFVC，我建议选择 Git。

创建您的第一个流水线

现在是创建第一个流水线的时候了。按以下步骤操作：

• 在 Pipelines 区域点击 Create Pipeline。

• 选择 Azure Repos Git 作为来源，并选择您的仓库。

• 您可以使用 YAML 或 Classic 编辑器配置流水线。我们选择 YAML，这是一种以代码定义流水线的方式。
• 保存流水线并运行，查看一切是否正常。

选择 YAML 与 Classic 编辑器

Azure Pipelines 提供两种定义流水线的方式：

• YAML 流水线： 以代码描述流水线。它们定义在源码仓库中的 .yaml 或 .yml 文件里，支持版本化与更好的协作。
• Classic 编辑器： Classic 编辑器提供友好的可视化拖拽界面，在复杂场景下灵活性较低。

根据我的经验，YAML 流水线对遵循基础设施即代码（IaC）实践的团队更为灵活与合适。但对新手而言，Classic 编辑器以更直观的方式上手也很不错。

不过，从长期可扩展性看，推荐优先采用 YAML 流水线而非 Classic 编辑器。

使用 Azure Pipelines 进行构建

现在，我们来看看如何通过 Azure Pipelines 进行构建。

本节将指定 Azure Pipelines 构建您代码所需的步骤，例如安装依赖、编译与运行测试。我们会在源码仓库中用 YAML 编写一个配置文件来表达这些步骤，YAML 是一种简单、可读性强的“配方式”描述方式。

YAML 流水线语法

下面是一个简单的 YAML 流水线示例：

# This section defines the trigger(s) for the pipeline.
# 'main' specifies that the pipeline will run whenever changes are pushed to the 'main' branch.
trigger:
- main  # automatically triggers this pipeline when changes are made to the 'main' branch.

# This defines the pool where the pipeline will run.
# 'ubuntu-latest' specifies the virtual machine image for executing tasks.
pool:
  vmImage: 'ubuntu-latest'  # This uses the latest Ubuntu image provided by Azure DevOps.

# Steps contain the individual tasks or actions that the pipeline will execute.
steps:
- script: echo Hello, world!  # A script task to run shell commands. This one prints "Hello, world!".
  displayName: 'Run my first pipeline script'  # A friendly name for this step, making it easier to identify in the pipeline logs.技术支持

我们逐步拆解上述代码：

• trigger：指定触发流水线的分支（如 main）。
• pool：定义构建代理（如 ubuntu-latest）。
• steps：列出要执行的任务，如安装依赖与运行构建脚本。

配置构建步骤

要在 YAML 流水线中添加构建步骤，您需要在“steps”部分下定义“script”。

以简单的 Node.js 应用为例，下面的 azure-pipelines.yml 文件包含 Azure DevOps 自动创建的代码。

# Node.js
# Build a general Node.js project with npm.
# Add steps that analyze code, save build artifacts, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/javascript

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

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

- script: |
    npm install
    npm run build
  displayName: 'npm install and build'技术支持

让我们看看上述 YAML 流水线中的构建 steps：

1. 安装 Node.js： 使用 NodeTool@0 任务指定 Node.js 版本。
2. 安装依赖： 运行 npm install 安装项目依赖。
3. 编译代码（构建项目）： 运行 npm run build 编译代码。

运行流水线

我们的流水线可以手动触发，也可以设置为在分支推送等事件发生时自动运行。

• 手动触发： 在 Azure DevOps 界面点击 Run Pipeline 即可手动触发。

• 自动触发： 根据仓库事件设置触发器，向 main 分支推送时自动触发流水线。示例：

trigger:
- main技术支持

运行流水线后，您可以查看日志并排查问题。

要访问日志，请进入流水线运行摘要并选择具体的作业或任务。该步骤会显示对应日志；如图所示，您可以选择任一作业（Build、Push 或 Update）查看原始日志。

要排查常见问题，您可以检查流水线是否存在超时、资源受限或配置错误等常见故障。

为流水线添加测试

向流水线添加测试，可确保代码质量，并在开发早期发现问题。在 Azure Pipelines 中，您可以通过在流水线配置中添加步骤来集成单元测试、集成测试或其他测试。

配置测试步骤

在流水线中加入测试步骤以保证代码质量。您可以使用 Jest、Mocha 或 NUnit 等流行框架。以下是使用 Jest 添加单元测试的示例：

- script: |
    npm test
  displayName: 'Run unit tests with Jest'技术支持

查看测试结果

Azure Pipelines 内置测试报告功能。您可以设置发布测试结果以便更易跟踪，并在流水线日志中查看测试结果。操作如下：

• 首先，导航到 Builds > Test Results。
• 要发布测试结果，使用 PublishTestResults@2 任务来展示结果，便于整体跟踪。例如：

- task: PublishTestResults@2
  inputs:
    testResultsFiles: '**/test-results.xml'
    testRunTitle: 'Unit Tests'技术支持

使用 Azure Pipelines 部署

在 Azure 流水线 YAML 文件中的部署步骤里，您可以自动将应用部署到多个环境，如测试、预发布和生产。本节将回顾几种使用 Azure Pipelines 进行部署的方式。

部署到 Azure Web Apps

Azure Web Apps 是 Azure 门户中的一项服务，可帮助您大规模地开发、部署与管理 Web 应用。

要部署到 Azure Web Apps，您需要将两项服务进行关联。步骤如下：

• 在项目左下角进入 Project Settings ， 点击 Service Connections （位于 Pipelines 部分下）。

• 点击 New Service Connection，选择 Azure Resource Manager。

• 使用您的 Azure 账户进行身份验证。
• 部署到 Azure App Service：
  • 返回 Pipelines 配置您的流水线。
  • 在流水线中添加部署到 Azure 的任务。
  • 指定资源组与服务详细信息。

下面是一个将简单 Node.js 应用部署到 Azure App Service 的 YAML 部署流水线示例：

# Define the task for deploying to an Azure Web App
- task: AzureWebApp@1
  inputs:
    # This specifies your Azure subscription service connection
    azureSubscription: 'your-azure-subscription'
    # This specifies the name of your web app
    appName: 'your-app-name'
    # This specifies the location of the app package or files to be deployed
    package: '$(Build.ArtifactStagingDirectory)'技术支持

我们来拆解以上代码，便于您按需调整：

• 将 your-azure-subscription 替换为可访问您 Azure 订阅的服务连接名称。
• 将 your-app-name 替换为 Azure 中您的实际 Web 应用名称。
• 将 $(Build.ArtifactStagingDirectory) 替换为用于部署的 Web 应用包或文件所在目录。$(Build.ArtifactStagingDirectory) —— 该变量指向构建产物（您的应用文件）在构建后存放的文件夹。

设置持续部署（CD）

当我们的代码通过所有测试与检查后，下一步就是设置持续部署。请按照以下步骤进行。

Azure 发布流水线部署模型（来源： Microsoft）

• 创建发布流水线：
• 前往 Pipelines > Releases 并点击 New Pipeline。

• 选择 Azure App Service Deployment 模板。

• 配置环境：
• 添加并配置 Dev、 Staging、 QA 与 Production 等您希望部署应用的环境。

• 通过选择 Add an artifact，将构建流水线的制品链接为发布流水线的来源。

• 配置审批与关卡：
• 对于生产等敏感环境，需要设置部署前审批。例如，可能需要团队负责人审批发布。您还可以添加自动化测试或监控检查等关卡，确保部署满足质量标准。

根据我的经验，这个阶段对于在高要求的开发环境中保持稳定性至关重要。审批与关卡提供了控制力，并确保只有高质量代码进入生产。

部署到 Kubernetes

Kubernetes 使运行可靠且可扩展的容器化应用变得更容易。使用 Azure Kubernetes Service（AKS）时，您将获得一个简化部署与运维的托管环境。本节我将演示如何使用 Azure Pipelines 将应用部署到 AKS。

准备 AKS 集群

您可以使用 Azure 门户或 CLI 创建 AKS 集群。下面是一个用于创建集群的基本 Bash CLI 命令：

az aks create \
  --resource-group <ResourceGroupName> \
  --name <AKSClusterName> \
  --node-count 3 \
  --enable-addons monitoring \
  --generate-ssh-keys技术支持

我们来拆解上述命令：

• --resource-group：指定创建 AKS 集群的 Azure 资源组。
• --name：集群名称。
• --node-count：集群中的节点数量（示例为 3）。
• --enable-addons monitoring：启用 Azure Monitor for Containers 的监控与分析。
• --generate-ssh-keys：如未提供，将自动生成用于安全访问节点的 SSH 密钥。

别忘了将 <ResourceGroupName> 与 <AKSClusterName> 替换为您的实际资源组与集群名称。

在 AKS 集群设置完成后，需要配置 kubectl。这样可确保您的流水线代理或本地计算机能通过 kubectl 与集群通信。

您可以通过命令行工具加速 Azure 任务——这份 Azure CLI 速查表非常实用。

创建部署 YAML 文件

下面以将 Docker 镜像部署到 Kubernetes 的基础部署 YAML 文件为例：

# This defines the API version and the kind of Kubernetes resource we are creating.
# 'apps/v1' is the API version, and 'Deployment' is the resource type.
apiVersion: apps/v1
kind: Deployment

# Metadata contains information to identify the resource uniquely.
# 'name' specifies the name of the Deployment.
metadata:
  name: my-app  # Name of the Deployment, used for identification.

# "spec" specifies the intended deployment state.
spec:
  # Number of replicas/pods we want for this Deployment.
  replicas: 3  # Ensures high availability by running three app replicas.

  # Selector is used to define the labels that this Deployment will manage.
  selector:
    matchLabels:
      app: my-app  # This ensures that only Pods with the label 'app: my-app' are managed by this Deployment.

  # Template specifies the blueprint for the pods created by the Deployment.
  template:
    metadata:
      labels:
        app: my-app  # Labels for the Pods, matching the selector above.

    # A specification for the containers of the Pods.
    spec:
      containers:
      - name: my-app  # Name of the container. This is useful for linking to the container in logs, etc.
        image: mycontainerregistry.azurecr.io/my-app:latest  # Pull the container image you will call from your container registry.
        ports:
        - containerPort: 80  # The container listens on port 80.技术支持

使用 Azure Pipelines 部署

在您的 YAML 流水线中，加入一个部署到 AKS 的任务。

# This defines a task for deploying Kubernetes manifests within an Azure DevOps pipeline.
- task: KubernetesManifest@0  # Task type for working with Kubernetes manifest files.
  inputs:
    # This configures what to do with the Kubernetes manifest files.
    action: 'deploy'  # 'deploy' action ensures the Kubernetes manifests are applied to the cluster.

    # This defines the namespace where the Kubernetes resources will be deployed.
    namespace: 'default'  # 'default' is the namespace for deploying resources. Change if needed.

    # All this does is point to the manifest files that define the desired state of your Kubernetes resources.
    manifests: '$(Build.ArtifactStagingDirectory)/manifests/*.yaml'
    # The 'manifests' variable points to the location of all the YAML files (e.g., Deployment, Service, etc.) that will be applied during the deployment.

    # To access private container registry images, use the image pull secret.
    imagePullSecrets: 'my-registry-secret'
    # This instructs Kubernetes on which secret to use when pulling images from a private container registry.
    # Ensure that 'my-registry-secret' exists in the namespace before the deploy技术支持

提交并推送该 YAML 文件以触发部署。

AKS 简化了容器编排，使扩缩容、更新与回滚更易管理。根据我的经验，它是现代云原生应用的必备之选。