[本文目錄]

ps: 閱讀本文大概需要20分鐘

歡迎大家點擊上方公眾號鏈接關注我，了解新西蘭碼農生活

什么是?YAML?

name/value 名稱/值

collections 集合

multiple data types 復合數據類型

comments 注釋

Pipelines 的 YAML 結構

在 Azure DevOps Pipelines 中創建第一個任務

為您的項目應用 Azure DevOps Pipelines

設置觸發器

設置作業池

運行第一個 Pipeline

向 Pipeline 添加任務

創建第一個 step

構建項目

為 .NET Core CLI 添加參數

發布 Artifact

打包代碼

使用變量

發布 Artifacts

將 *.nupkg 文件發布到 NuGet 包源

創建 release pipeline

添加 Artifact

添加任務

創建 release

在 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

了解新西蘭IT行業真實碼農生活
請長按上方二維碼關注“程序員在新西蘭”

總結

以上是生活随笔為你收集整理的使用Azure Pipelines从GitHub发布NuGet包的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。