使用Azure Pipelines从GitHub发布NuGet包

[本文目录]

ps: 阅读本文大概需要20分钟
欢迎大家点击上方公众号链接关注我，了解新西兰码农生活

什么是 YAML?
1. name/value 名称/值
2. collections 集合
3. multiple data types 复合数据类型
4. comments 注释
Pipelines 的 YAML 结构
在 Azure DevOps Pipelines 中创建第一个任务
1. 为您的项目应用 Azure DevOps Pipelines
2. 设置触发器
3. 设置作业池
4. 运行第一个 Pipeline
向 Pipeline 添加任务
1. 创建第一个 step
2. 构建项目
3. 为 .NET Core CLI 添加参数
发布 Artifact
1. 打包代码
2. 使用变量
3. 发布 Artifacts
将 *.nupkg 文件发布到 NuGet 包源
1. 创建 release pipeline
2. 添加 Artifact
3. 添加任务
4. 创建 release
5. 在 NuGet 上检查包
结语

长久以来我已经习惯使用经典的编辑器来配置 Azure DevOps Pipelines，该编辑器允许我们使用对用户友好的图形界面来配置 pipeline 的各种属性。但是配置 pipeline 的更好方法是使用YAML文件。您可以轻松调整 pipeline 的每个选项，并轻松克隆和共享。现在 YAML 已经是 Azure DevOps 中配置 pipeline 的默认模板。我已经开发了一个简单的 NuGet 程序包（为WPF, UWP 及 Xamarin实现一个简单的消息组件），该包集成了 Azure DevOps 来进行构建和发布。我将演示如何使用YAML文件创建新的 pipeline。在开始之前，让我们花一些时间来初步了解YAML。

1.什么是 `YAML`?

YAML（YAML不是标记语言）是一种适用于所有编程语言的对人类友好的数据序列化标准。

-- yaml.org^[1]

YAML被设计为对人类友好，并且可以很好地与现代编程语言配合工作。它类似JSON。实际上，您可以将 YAML 作为JSON的超集。每个JSON文件也是一个有效的YAML文件。但是不同之处在于它们有不同的优先级。JSON 的首要目标是简单性和通用性，因此很容易在每种现代编程语言中生成和解析。但是对于YAML，首要的设计目标是提高人类的可读性。因此，YAML的生成和解析更加复杂。

想象一下如何描述基本的数据结构？有三个基本但非常重要的基元：mappings（即映射，如哈希/字典），sequences（即序列，如数组/列表）和 scalars（即标量，如字符串/数字）。我们可以这样描述JSON的结构：

一个 name/value 的 collection。一个object以 {开头，以}结尾。每个名称后都带有:，name/value 之间以,分隔。
一个 value 的 list/array。一个array 以[开头，以]结尾。value 以,分隔。
一个 value 可以是双引号中的字符串，或者是数字，或者是true或false或null，或者是 object 或 array。这些结构可以嵌套。

YAML和JSON之间有一些相似之处。让我们看一下在YAML中如何实现这些特性。但由于 Azure DevOps Pipelines 不支持YAML的所有功能，因此我们不会介绍YAML的所有详细信息。

1.1 name/value 名称/值

YAML也包含一组 name/value 对，但不需要使用{和}。: 的左边是名称，:的右边是值。例如：

name: myFirstPipeline

注意，YAML中的 string 不需要用引号。但也可以用引号。

值可以是字符串或数字，也可以是 true，false或null或一个 object。YAML 使用缩进来表示嵌套对象。最好使用 2 个空格缩进，但不是必需的。例如：

variables:
  var1: value1
  var2: value2

1.2 collections 集合

YAML 使用[] 来表示数组或集合。例如：

sequence: [1, 2, 3]

另一种方式是使用 -，如下所示：

sequence:
  - item1
  - item2

1.3 multiple data types 复合数据类型

|表示关键字有多种数据类型。例如，job | templateReference表示该值允许是一个 job 或 template reference。

1.4 comments 注释

JSON不支持注释，但是可以在YAML中使用#进行注释。

2. Pipelines 的 `YAML` 结构

在 Azure DevOps 中设置 Pipelines 时，我们使用 Stages、 Jobs 和 Tasks 来描述 CI/CD 流程。一个 pipeline 可能包含一个或多个 Stage，例如 Build the app 和 Run tests 等。每个 Stage 都包含一个或多个 Job。每个 Job 都包含一个或多个 Task。让我们看一下 pipeline 的YAML文件的层次结构：

YAML文件的层次结构

您不需要所有级别，因为有时 pipeline 仅包含几个 Job，因此只需针对您的特定需求定制步骤即可。

3. 在 Azure DevOps Pipelines 中创建第一个任务

3.1 为您的项目应用 Azure DevOps Pipelines

您可以在 Azure DevOps Repo 或 GitHub 上托管项目。Azure DevOps Pipelines 支持许多存储库提供程序，例如 GitHub，Bitbucket 或其他 Git 系统。

如果您的项目托管在 GitHub 上，则可以轻松地从 GitHub Marketplace 安装 Azure Pipelines 插件：

安装 Azure Pipelines 插件

在 Marketplace 中搜索 pipeline，然后点击 Azure Pipelines，按照向导将其安装到项目中。接下来，您可以在 Azure DevOps 中看到您的项目。

另一种方法是在 Azure DevOps 中创建一个新的空白项目，然后仅启用所需的模块（如仅启用 Pipelines，无需启用 Repos）。然后连接到您在 GitHub 上的项目存储库，并按照指南构建第一个 pipeline。

让我们创建一个新的 pipeline 来构建项目。在 Azure DevOps 菜单中单击 Pipelines，然后选择 Builds：

Azure DevOps 菜单

单击 New - New build pipeline:

创建新pipeline

Azure DevOps Pipelines 会请求项目位置：

选择项目位置

如果您喜欢经典的带界面的编辑器，请单击 Use the classic editor。但是这次，我将使用 YAML。因此，我单击 GitHub(YAML) 选项，然后选择存储库。Azure Pipelines 将分析存储库，并为项目推荐 Pipeline 模板。如果 Azure Pipelines 无法分析您的项目是什么类型，也可以手动进行配置：

配置项目类型

我将从头开始构建 pipeline。因此，我选择了 Starter pipeline。显然，您可以为项目的特定类型选择一个模板，以简化流程。您也可以单击 Show more 以检查更多可用模板。

选择模板后，Azure Pipelines 将在仓储库的根目录下创建一个名为azure-pipelines.yml的文件。Starter pipeline 的默认模板如下所示：

# Starter pipeline
# Start with a minimal pipeline that you can customize to build and deploy your code.
# Add steps that build, run tests, deploy, and more:
# https://aka.ms/yaml

trigger:
- master

pool:
  vmImage: 'ubuntu-latest'

steps:
- script: echo Hello, world!
  displayName: 'Run a one-line script'

- script: |
    echo Add other tasks to build, test, and deploy your project.
    echo See https://aka.ms/yaml
  displayName: 'Run a multi-line script'

文件的内容可能会因项目而异。

您可以通过单击文件名链接来更改文件名：

更改 YAML 文件名称

3.2 设置触发器

我们已经了解了YAML的基础知识。让我们看一下该 YAML文件的内容。第一个关键字是 trigger，表示 Push 触发器。它指定当您推送更改到哪个分支时将导致构建过程。如果未指定此值，则每次 Push 代码到任何分支都会触发构建。

对于 trigger 键，有不同的选项，但是目前我们只需要知道，我们可以在此处设置分支名称即可，如下所示：

trigger:
- master

如果要添加更多分支，只需添加以下元素：

trigger:
- master
- develop

您还可以为branches，tags 和paths配置include和exclude 。完整语法为：

trigger:
  batch: boolean # batch changes if true (the default); start a new build for every push if false
  branches:
    include: [ string ] # branch names which will trigger a build
    exclude: [ string ] # branch names which will not
  tags:
    include: [ string ] # tag names which will trigger a build
    exclude: [ string ] # tag names which will not
  paths:
    include: [ string ] # file paths which must match to trigger a build
    exclude: [ string ] # file paths which will not trigger a build

您可以使用通配符指定标签的分支。通配符模式允许您使用 * 匹配零个或多个字符，并使用 ? 匹配单个字符。有关更多详细信息，请访问：触发器中的通配符^[2]。

触发器的另一种类型是PR 触发器，它指定向哪些分支提交 Pull Request 将会导致构建。但是请记住，此功能仅适用于 GitHub 和 Bitbucket Cloud。如果您使用的是 Azure DevOps Repos，则可以配置用于生成验证的分支策略^[3]触发构建以进行验证。

我正在使用 GitHub，因此我使用以下代码进行配置，对 master 分支有新的 Pull Request 时将会触发构建：

pr:
- master

3.3 设置作业池

pool 用于指定要用于作业的池。完整语法为：

pool:
  name: string  # name of the pool to run this job in
  demands: string | [ string ]  ## see below
  vmImage: string # name of the vm image you want to use, only valid in the Microsoft-hosted pool

Azure DevOps 为我们提供了许多由 Microsoft 托管的池。您可以在这里找到它们：由 Microsoft 托管的作业代理^[4]

当然，您也可以使用私有池，但需要首先创建构建代理，不过这超出了本文的范围。

我想在 Windows 平台上构建项目，因此将 vmImage 更改为 windows-2019，即运行 Visual Studio 2019 的 Windows Server 2019。因此该配置将是：

pool:
  vmImage: 'windows-2019'

如果您正在开发.NET Core 应用程序，则可以通过以下代码使用 Linux 平台（例如 Ubuntu）：

pool:
  vmImage: 'ubuntu-latest'

3.4 运行第一个 Pipeline

下面的部分是一些脚本。在更改它们之前，我们可以先保存 Pipeline 并尝试运行它。点击右上角的 Save and run。您可以在保存之前更改提交消息。您将看到如下所示的结果：

运行结果

实际上，此默认 Pipeline 模板仅显示如何运行输出回显消息的单行脚本和多行脚本。我们还需要添加任务来构建项目。

4. 向 Pipeline 添加任务

让我们看一下 Pipeline 任务的层次结构。我们可以使用 Stage、 Job 和 Step 对任务进行分类。基本上，一个Stage 是一系列 Job 的集合。Job 是 Step 的集合。Step 是组成一项 Job 的一系列特定操作，例如运行一段脚本或复制文件。下面是一个示例：

stages:
- stage: Build
  jobs:
  - job: BuildJob
    steps:
    - script: echo Building!
- stage: Test
  jobs:
  - job: TestOnWindows
    steps:
    - script: echo Testing on Windows!
  - job: TestOnLinux
    steps:
    - script: echo Testing on Linux!
- stage: Deploy
  jobs:
  - job: Deploy
    steps:
    - script: echo Deploying the code!

如前所述，您不需要全部。如果您的 pipeline 只有一个 Stage 和一个 Job，则可以省略 stage 和 job，而仅使用 steps。

4.1 创建第一个 step

我倾向从最简单的方法开始。因此，让我们忽略 stage 和 job。首先，我将添加 steps 来构建项目。第一步是安装 .NET Core SDK。

删除默认 pipeline 中的 echo 脚本，然后添加 steps 部分，如下所示：

steps:
- task: UseDotNet@2
  displayName: 'Install .NET Core SDK'
  inputs:
    packageType: 'sdk'
    version: '2.x'

请不要只复制并粘贴它。尝试手动输入以测试功能强大的 Azure DevOps Pipelines 编辑器。当您为任务名称输入 dotnet 时，您会发现编辑器会自动显示一个包含此关键字的列表：

智能感知

这与 Visual Studio 中的智能感知类似。用向上或向下移动键然后按回车选择 UseDotNet@2。添加后，您会发现任务上方有一个灰色的 Settings 链接：

任务设置

点击Settings，您将在右侧看到配置面板：

任务配置面板

它节省了我们记住参数名称的时间。在 Version 文本框中输入2.x，然后单击 Add。该任务将添加到 pipeline 中：

配置参数

编辑器支持出色的智能感知，当您键入内容时，你会看到编辑器的实时提示：

智能感知

下一个问题是，我们如何知道需要使用的参数？对于.NET Core 工具，请在此处查看文档：使用.NET Core 任务^[5]

Azure DevOps Pipelines 支持许多任务，例如生成任务，工具任务，测试任务，部署任务和实用程序任务等。您可以在此处找到支持的任务列表：构建和发布任务^[6]

4.2 构建项目

现在，我们已经为项目安装了.NET Core SDK。接下来，我们需要调用 .NET Core CLI 来构建项目。在当前 steps 部分中添加一个新任务，并选择 DotNetCoreCLI@2，因为我们使用的是 .NET Core v2.x。当您看到任务上方的 Settings 链接时，可以在任务配置面板中轻松配置它：

任务配置面板

新任务如下所示：

- task: DotNetCoreCLI@2
  inputs:
    command: 'build'
    projects: 'FunCoding.CoreMessenger/FunCoding.CoreMessenger/FunCoding.CoreMessenger.csproj'

当您指定项目路径时，可以使用通配符（如使用 **/*.csproj 匹配所有子目录下的所有*.csproj 文件）。您还可以指定 build 命令的参数。

现在让我们使其尽可能简单。单击右上角的 Save ，输入您的提交消息，然后单击 Save：

保存 pipeline

保存 pipeline 后，可以通过单击右上角的 Run 来运行它。选择正确的 branch 或 tag，然后单击 Run：

运行 pipeline

您将看到 pipeline 正常运行：

pipeline 运行结果

4.3 为 .NET Core CLI 添加参数

当我们使用 .NET Core CLI 的 dotnet build 命令时，默认配置为 debug。我们需要指定release模式。因此，我们可以添加一个configuration参数，如下所示：

- task: DotNetCoreCLI@2
  displayName: 'Build the project'
  inputs:
    command: 'build'
    configuration: 'Release'
    projects: 'FunCoding.CoreMessenger/FunCoding.CoreMessenger/FunCoding.CoreMessenger.csproj'

如果我们只需要一个验证 PR 的 build pipeline，这已经足够了。我们只需要验证构建，而无需打包和发布软件包。但是对于发布流程来说，我们需要打包项目并生成* .nupkg文件。因此，让我们继续实现打包及发布。

5. 发布 Artifact

下一步是使用 .NET Core CLI 的 dotnet pack 命令将代码打包到 NuGet 包中，然后将其发布到一个文件夹中。

5.1 打包代码

dotnet pack 命令用于构建项目并创建 NuGet 软件包。我们需要添加另一个任务来使用此命令。选择DotNetCoreCLI@2任务，然后单击Settings：

任务配置

我们需要选择 pack 命令。然后选择要打包的项目的正确路径。我们可以将 Configuration to Package和Package Folder 保留为默认值。对于 Do not build 复选框，我们可以将其选中，因为在上一个步骤中，我们已经完成了构建。在 Pack options 中，我们可以选择版本控制模式。更多细节可参考：

版本方案
对于 byPrereleaseNumber，版本将设置为您为主要，次要和补丁选择的任何内容，以及日期和时间，格式为 yyyymmdd-hhmmss。
对于 byEnvVar，版本将设置为您提供的环境变量，例如 MyVersion（没有**$**，仅是环境变量名称）。确保将环境变量设置为正确的 SemVer，例如 1.2.3或1.2.3-beta1。
对于 byBuildNumber，版本将设置为构建版本号，请确保您的构建版本号是正确的 SemVer，例如 1.0.$(Rev:r)。如果选择 **byBuildNumber **，该任务将提取一个由点分隔的版本“ 1.2.3.4”，并仅使用该版本，并删除所有标签。要按原样使用构建版本号，您应该如上所述使用 byEnvVar，并设置BUILD_BUILDNUMBER 环境变量。

对于此演示，我不想将其作为正式版本发布到 NuGet。所以我选择byPrereleaseNumber。它会在Major.Minor.Patch 版本之后附加一个后缀，因此它会显示为一个预发行版本。预发行版本是带有-的标签，后面添加您想要的字母和数字。例如，版本 1.0.0-beta，1.0.0-build12345 都是 1.0.0 的预发行版本。这称为 SemVer，表示语义化版本号。您可以在这里找到更多详细信息：Semantic Versioning^[7]。当我们需要发布正式版本时，我们将不使用这种类型的打包选项。一种简便的方法是在 *.csproj 文件中对版本号进行硬编码，然后在此处将 Pack options 设置为 Off。但这意味着每次发布新版本都要更改*.csproj文件。还有一种方式是对dotnet pack命令使用参数如：dotnet pack -p:PackageVersion=2.1.0。我们还可以找到其他一些工具来简化我们的工作，例如 DotNetTools^[8]。您可以使用工具或直接编写 PowerShell 脚本来更新版本号。

pack 任务如下所示：

- task: DotNetCoreCLI@2
  displayName: 'Pack the package'
  inputs:
    command: 'pack'
    configuration: 'Release'
    packagesToPack: 'FunCoding.CoreMessenger/FunCoding.CoreMessenger/FunCoding.CoreMessenger.csproj'
    nobuild: true
    versioningScheme: 'byPrereleaseNumber'
    majorVersion: '1'
    minorVersion: '0'
    patchVersion: '0'

如果 pipeline 正常运行，它将打包项目并将打包后的* .nupkg文件生成到$(Build.ArtifactStagingDirectory)中，该目录是 Azure DevOps 的预定义变量。您可以在此处找到预定义变量的相关内容：预定义变量^[9]。

5.2 使用变量

目前，我们尚未指定构建配置。大多数项目的默认值为 Debug。所以我们需要给这个参数指定 Release。另外，我们发现这两个任务都包含项目路径。因此，我们可以使用变量来简化脚本。

变量允许我们定义一些可重复使用的键/值对。这也是避免在脚本中进行硬编码的好方法。当 Azure DevOps Pipelines 执行任务时，变量将被替换为正确的值。

如上一节所述，Azure DevOps 已经提供了一些预定义的变量。我们还可以定义自己的变量。让我们在 pool 部分之后添加一些变量：

variables:
  configuration: 'Release'
  projectPath: 'FunCoding.CoreMessenger/FunCoding.CoreMessenger/FunCoding.CoreMessenger.csproj'

然后我们可以使用$(variableName)在任务中应用这些变量：

- task: DotNetCoreCLI@2
  displayName: 'Build the project'
  inputs:
    command: 'build'
    configuration: $(configuration)
    projects: $(projectPath)

- task: DotNetCoreCLI@2
  displayName: 'Pack the package'
  inputs:
    command: 'pack'
    configuration: $(configuration)
    packagesToPack: $(projectPath)
    nobuild: true
    versioningScheme: 'byPrereleaseNumber'
    majorVersion: '1'
    minorVersion: '0'
    patchVersion: '0'

Pipeline 将按预期工作。

实际上，我们可以接着使用dotnet push命令在 build pipeline 中将其推送到 NuGet 的包源。但这有点混淆了 build 与 release，因为理论上 build pipeline 只应执行构建工作。因此，我将创建另一个 release pipeline 将其推送到 NuGet 包源。

5.3 发布 Artifacts

下一步是发布 NuGet 包文件，以便 release pipeline 能够将其推送到 NuGet 包源。通过键入 publish 来添加新任务，然后选择 PublishBuildArtifacts@1：

添加新任务

您可以在此处找到有关此任务的更多详细信息：发布构建 Artifacts 任务^[10]

单击 Settings ，并保留默认设置，然后单击 Add：

任务配置

打包项目时，Package Folder 的默认设置为 $(Build.ArtifactStagingDirectory)。因此，在发布步骤中，任务将从 $(Build.ArtifactStagingDirectory) 中获取打包好 NuGet 包文件，并将其发布到 Azure Pipelines 或文件共享。该脚本如下所示：

- task: PublishBuildArtifacts@1
  displayName: 'Publish the package'
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)'
    ArtifactName: 'drop'
    publishLocation: 'Container'

好的，现在触发此 pipeline 后，它将构建项目，然后打包并将 NuGet 程序包发布到 Azure Pipelines。我们可以在 build pipeline 结果页面上单击 Artifacts，然后单击 drop：

查看Artifacts

我们可以看到打包好的 *.nupkg 文件:

Artifacts 文件

注意，每次编译后，* .nupkg文件的名称后缀都会更改。因为上一个步骤中我们为pack任务选择了byPrereleaseNumber。如果您选择了其他的版本方案，名称会有所不同。

6. 将 `*.nupkg` 文件发布到 NuGet 包源

通常，我们应该有一个名为 release 的分支来发布软件包。但是为了简单起见，我继续将 master 分支用于 release pipeline。请记住，这不是 GitFlow 的最佳实践。我只想专注于YAML的内容。您可以在脚本中轻松更改目标分支。

6.1 创建 release pipeline

让我们创建一个 release pipeline。单击 Azure DevOps 菜单中的 Pipelines，然后单击右侧的 Releases ：

Azure DevOps Releases菜单

在新窗口中，单击 New pipeline 。您将看到如下页面：

添加新pipeline

我们将从头开始创建 pipeline，因此请单击 Empty job：

release pipeline 配置

6.2 添加 Artifact

单击Add an artifact，然后您将看到一个页面用来配置 Artifact：

添加 Artifacts

为发布选择正确的 build pipeline。然后点击 Add。Artifact 将显示在这里：

选择好的 Artifact

6.3 添加任务

然后点击 Stage 1 下方的 1 job, 0 task 链接。您可以更新 Stage 和作业代理的详细信息：

任务配置

点击 Job 右侧的 +：

添加任务

您将看到一个页面，显示 Azure DevOps 中的所有可用任务：

可用任务列表

在我写作这篇文章之前，我以为可以使用 dotnet push 命令将程序包推送到 NuGet 程序包源，所以选择了 .NET Core 任务，并从 Command 列表中选择了 nuget push 命令。但是发现 .NET Core CLI 抛出了错误：

Error: DotNetCore currently does not support using an encrypted Api Key.
Packages failed to publish

我在 GitHub 上发现了一个问题：DotNetCore currently does not support using an encrypted Api Key^[11]。目前，.NET Core CLI 当前不支持使用 ApiKey 的方式，因为加密密钥所需的库不可用。因此，我们需要使用 NuGet Tool 来推送软件包：

选择 NuGet 任务

这里的配置有点小坑。Path to NuGet package(s) to publish 的默认值是$(Build.ArtifactStagingDirectory)/**/*.nupkg;!$(Build.ArtifactStagingDirectory)/**/*.symbols.nupkg 。但是 release pipeline 将 artifacts 下载到了 System.ArtifactsDirectory，因此我们需要使用 $(System.ArtifactsDirectory)/**/*.nupkg。否则的话 release pipeline 会找不到 build pipeline 发布的 Artifacts。您可以在此处找到一些信息：NuGet 任务^[12]。有关 Artifacts 的更多内容，请在此处查看文档：发布 Artifacts 和 Artifacts 源^[13]。

下一个重要的事情是我们需要创建与 NuGet 服务器的连接。如果要将 NuGet 程序包发布到您的组织，请选择This organization/collection 作为 Target feed location。我正在将其发布到 NetGet，所以我选择External NuGet server (including other organizations/collections)。

如果尚未创建与 NuGet 服务器的连接，请单击 +New 以创建一个。您可以在 NuGet 门户中找到您的 ApiKey。Feed URL 应为https://api.nuget.org/v3/index.json。

创建 NuGet 服务连接

单击右上角的 Save 以保存配置。任务的最终配置如下所示：

NuGet 任务配置

这个任务非常简单，因为我们只需要使用一个命令。如果您还有更多任务，只需添加它们即可。您还可以为不同的环境创建不同的 Stage，例如 Dev，Stage 或 Prod。

6.4 创建 release

点击 Create release，您将看到用于配置发布的页面：

创建发布

单击 Create 以开始发布。然后返回该发布的详细信息页面，单击 Deploy：

开始部署

您将看到一个用于部署的新页面：

启动部署

单击 Deploy ，release pipeline 将启动发布。

如果 release pipeline 成功发布，则可以看到如下所示的结果：

发布结果

6.5 在 NuGet 上检查包

现在登录 NuGet，可以看到该预发布版本的软件包已经显示在这里：

检查 NuGet 上的包

请记住，带有自动后缀（如1.0.0-CI-10191202-034430）的软件包是预发行版本。因为我们在pack任务中选择了byPrereleaseNumber。如果要发布正式版本，则需要通过其他方式指定版本号。在 CI/CD 中，版本控制是另一件需要注意的事情。但是我想在这里停止，因为本文旨在展示如何从头开始编写YAML文件。我们没有涵盖 Git Flow 的全部细节，例如分支策略等。希望通过本文您能对YAML有一个基本的了解，并且能够开始编写第一个YAML文件。

7. 结语

最终的 build pipeline 的 YAML 文件如下所示：

trigger:
- master

pool:
  vmImage: 'windows-2019'

variables:
  configuration: 'Release'
  projectPath: 'FunCoding.CoreMessenger/FunCoding.CoreMessenger/FunCoding.CoreMessenger.csproj'

steps:
- task: UseDotNet@2
  displayName: 'Install .NET Core SDK'
  inputs:
    packageType: 'sdk'
    version: '2.x'

- task: DotNetCoreCLI@2
  displayName: 'Build the project'
  inputs:
    command: 'build'
    configuration: $(configuration)
    projects: $(projectPath)

- task: DotNetCoreCLI@2
  displayName: 'Pack the package'
  inputs:
    command: 'pack'
    configuration: $(configuration)
    packagesToPack: $(projectPath)
    nobuild: true
    versioningScheme: 'byPrereleaseNumber'
    majorVersion: '1'
    minorVersion: '0'
    patchVersion: '0'

- task: PublishBuildArtifacts@1
  displayName: 'Publish the package'
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)'
    ArtifactName: 'drop'
    publishLocation: 'Container'

在本文中，我介绍了 YAML是什么以及如何从头开始定义 YAML 文件。Azure DevOps Pipelines 为我们提供了一个具有智能感知能力的优秀编辑器，可用来轻松编写 YAML文件，当然您也可以使用配置面板更新属性。我们没有涵盖有关 CI/CD 的所有详细信息。请检查 GitFlow^[14] 并应用正确的分支策略。希望本文对您编写第一个YAML文件有所帮助。谢谢。

更多关于 Azure DevOps Pipelines 的内容，请参阅：Azure Pipelines 文档^[15]。

参考资料

[1]

yaml.org: https://yaml.org/

[2]

触发器中的通配符: https://docs.microsoft.com/zh-cn/azure/devops/pipelines/build/triggers?WT.mc_id=DT-MVP-5001643&view=azure-devops&tabs=yaml#wildcards

[3]

用于生成验证的分支策略: https://docs.microsoft.com/zh-cn/azure/devops/repos/git/branch-policies?WT.mc_id=DT-MVP-5001643&view=azure-devops#build-validation

[4]

由Microsoft托管的作业代理: https://docs.microsoft.com/zh-cn/azure/devops/pipelines/agents/hosted?WT.mc_id=DT-MVP-5001643&view=azure-devops#use-a-microsoft-hosted-agent

[5]

使用.NET Core任务: https://docs.microsoft.com/zh-cn/azure/devops/pipelines/tasks/tool/dotnet-core-tool-installer?WT.mc_id=DT-MVP-5001643&view=azure-devops

[6]

构建和发布任务: https://docs.microsoft.com/zh-cn/azure/devops/pipelines/tasks/?WT.mc_id=DT-MVP-5001643&view=azure-devops

[7]

Semantic Versioning: https://semver.org/

[8]

DotNetTools: https://github.com/RicoSuter/DNT

[9]

预定义变量: https://docs.microsoft.com/en-us/azure/devops/pipelines/build/variables?WT.mc_id=DT-MVP-5001643&view=azure-devops&tabs=yaml

[10]

发布构建 Artifacts 任务: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/publish-build-artifacts?WT.mc_id=DT-MVP-5001643&view=azure-devops

[11]

DotNetCore currently does not support using an encrypted Api Key: https://github.com/microsoft/azure-pipelines-tasks/issues/7160

[12]

NuGet任务: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/package/nuget?WT.mc_id=DT-MVP-5001643&view=azure-devops#examples

[13]

发布Artifacts和Artifacts源: https://docs.microsoft.com/en-us/azure/devops/pipelines/release/artifacts?WT.mc_id=DT-MVP-5001643&view=azure-devops#download

[14]

GitFlow: https://datasift.github.io/gitflow/IntroducingGitFlow.html

[15]

Azure Pipelines 文档: https://docs.microsoft.com/zh-cn/azure/devops/pipelines/?WT.mc_id=DT-MVP-5001643&view=azure-devops