[Azure DevOps] Azure Build Pipeline 簡介

How to Build an Azure Pipeline (Build/Release) from Scratch(圖片來源:https://morioh.com/p/15bbac48c8e7

 

Azure Build Pipeline 提供程式碼持續整合功能,

能執行建置、測試、Artifact 產出及自訂 Script 等工作,

本文將簡介如何透過 Azure DevOps 快速打造一條 Build Pipeline。

 

前言

近年來軟體建置及佈署流程漸漸受到重視,

透過許多工具可協助我們完成持續整合與持續交付的目標。

本文將簡介如何透過 Azure DevOps 快速打造一條 Build Pipeline。

在開始前請先確定您的 Repos 中已有可建置的程式碼專案,

本文以 ASP.Net Core MVC 3.1 範本專案為例。

 

新增 Build Pipelines 

Azure DevOps Pipeline

請點選左側 Pipelines > Pipelines

其實原本叫做Builds

但某次改版後就更名成 Pipelines 了,

這命名其實容易讓人造成混淆,

希望還有機會改回來。

 

接著從左上方點選 New Pipelines 新增 Build Pipeline,

並選擇程式碼來源,

這邊我們選擇Azure Repos Git 並使用預設的 YAML 格式檔,

如果想要用過去介面的方式設定,

也可以從下方選擇 Use the classic editor 進行配置。

 

接著選擇 Repository 及專案組態範本。

 

完成後 Azure DevOps 會產出一份預設的 YAML 樣板,

它可以說是整個 Build Pipeline 的靈魂,

舉凡建置、測試、Artifact 產出及執行自訂 Script 等流程,

都可在這裡進行設定,

檔名預設為 azure-pipeline.yml

trigger:
- master

pool:
  vmImage: 'windows-latest'

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'

steps:
- task: NuGetToolInstaller@1

- task: NuGetCommand@2
  inputs:
    restoreSolution: '$(solution)'

- task: VSBuild@1
  inputs:
    solution: '$(solution)'
    msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DesktopBuildPackageLocation="$(build.artifactStagingDirectory)\WebApp.zip" /p:DeployIisAppPath="Default Web Site"'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

- task: VSTest@2
  inputs:
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

 

這邊簡單介紹一下各區塊的用途:

  • trigger:觸發建置的來源,通常設定為分支,也可設定使用 tag 等方式進行觸發。
  • pool:設定 Build Server 的 Agent Pool。使用官方提供的 Microsoft-hosted 需指定 vmImage 版本;若為自架的 host,則直接指定 pool 名稱即可。
  • variables:除預定義變數之外,可將變數定義於組態檔內,但也可透過一些 Shell Script 來做(如使用 PowerShell 於 Build Pipeline 中自訂 GitShortHash 變數)。
  • steps:設置於 Build Server 上執行工作流水線,由許多自定義的 task 所組成,@ 後面為該 task 最新版號
    • NugetToolInstaller:下載指定版本(預設為最新)的 Nuget CLI 工具,若為官方提供的 pool 則會定期更新至穩定版本;要注意若使用最新版本可能導致執行過程 Crash 。
    • NugetCommand:可透過 Nuget 工具進行套件還原、打包及發佈功能,也可指定套件來源(官方、Artifact Feeds、自建 Nuget Server)等資訊。
    • VSBuild:可指定 Visual Studio 版本建置整個 solution(預設為最新版,如:VS2019),骨子裡其實也是跑 MSBuildmsbuildArgs 屬性可進行建置流程細部設定。若只想針對單一專案 .csproj 建議選用 MSBuild
    • VSTest:執行單元性及功能性測試,在使用前須確保 Build Server 已安裝 VSTest,或使用 VisualStudioTestPlatformInstaller 進行安裝。

上述又可依執行環境分為兩大類:

  • Repo Server :在版控伺服器上執行,大多為建置所需的靜態參數設定。如:trigger、pool、variables等。
  • Build Server :定義相依於建置伺服器上執行的工作,如建置、測試及 Artifact 產出等。

為什麼要特別分執行環境呢?

因為在使用預定義變數時是有範圍限制的,

例如 Build variables 僅能在建置階段使用,

Deployment job variables 僅能在佈署階段等等。

而在自訂建置流程時經常會需要使用預定義變數,

如果沒有仔細檢查每個變數的執行範圍,

很容易因空值導致不預期的結果。

建議可在需要自訂 Script 時,

搭配 output console 的方式來進行驗證。

 

這邊介紹一個還不錯的小功能,

task 上點選 Settings

會自動在左側帶出 GUI 輔助工具,

能進行一些簡單的設定,

但比較細項的部分還是得手動調整 config。

 

講了這麼多,我們來 Run 一下看看建置結果如何。

在介面上可以看到許多資訊,

像是 BuildNumber、Commit Message、Trigger Branch、Commit Hash Code,

這些資訊能夠提供我們快速有效地識別建置觸發來源,

而觀察執行時間可作為反饋速度改善的評估依據。

 

點進去後可以條列查看每個項目的執行狀況,

能夠協助我們在執行錯誤時輔助偵錯。

 

結語

打造自己的建置流水線是一件很妙的過程,

它可能會因為不同的開發流程及組織產生略為的變化。

而你會發現因應實務上的需要,

經常要透過撰寫一堆 Script 來完成(如使用 PowerShell 於 Build Pipeline 中自訂 GitShortHash 變數)。

這對身為開發者的我而言是相當有趣的。

另外一題紙本理論的閱讀雖然是重要的,

但如若不動手親自做一番,

可能永遠無法體會持續交付的真諦。

 

參考

Predefined Variables - MSDN

CI Trigger - MSDN

Agent Pools - MSDN

Microsoft-hosted agents - MSDN