CI/CD從這裡：設定第一個Pipeline(範本與編輯介面)

前一篇介紹了要用來作為建立Pipeline的材料，這篇就要開始來建立第一個Build Pipeline，也是CI(Continue Integration)的第一步。

在Azure DevOps中建立Pipeline有兩個入口，一個是直接從程式碼倉庫Repos底下的Files功能頁面點選Set up build功能按鈕：

另一個方式是從Pipelines底下的Pipelines(好繞口)頁面中點擊Create Pipeline：

兩個方式差異並不大，只是如果從Repo中點選Set up build，代表就是以該Repo做為程式碼的來源，所以會跳過下面的第一步：

從上圖可以看到有幾個不同來源的選擇，如果程式碼都是放在Azure DevOps的Git Repo，那麼就是選擇第一個Azure Repos Git，如果是GitHub選第三個，如果是GitLab的話就選擇Other Git，TFVC Repo則是選擇最下面的Team Foundation Version Control。

最下面還有一行文字：「Use the classic editor to create a pipeline without YAML」，如果是早期就已經有使用Azure DevOps建立Pipeline的人也可以選擇舊的編輯器，這邊先暫時放一邊，後面會有機會再來看一下它。

第一步選擇完程式碼的來源之後，或是從Repo中直接點選Set up build的功能跳過上述第一步，接下來就是選擇要建立什麼樣的Pipeline：

從上圖可以看到有ASP.NET、ASP.NET Core、.NET Desktop…，除了下面的Starter pipeline、Existing Azure Pipelines YAML file之外，其它的每一種都只是針對不同的程式提供不同的Pipeline YAML範本，如果點選下面的Show more還可以看到更多範本如下圖：

下面這個是選擇「.NET Desktop」範本的Pipeline yaml內容：

而下面這個則是選擇「Starter pipeline」範本的Pipeline yaml內容：

可以上下比較一下兩個Yaml檔內容差異，在繼續說明之前再用下面這張圖來說明一下幾個介面操作的地方：

第一件事就是更改yaml檔案的檔名，預設是azure-pipelines.yml，每建立一個Pipeline都會有一個Yaml檔案，它會儲存在Repository裡面 ，從檔名前面就可以看到儲存的Repo是哪一個。檔名中可以包含資料夾的名稱加上斜線再接實際的檔案名稱，這樣Yaml檔就會被放在指定的資料夾中歸檔。

再來是右上角的Save and run按鈕，有時候只是先編輯一下Yaml檔，還沒有要讓它實際執行的時候就需要按右邊的向下箭頭，之後選擇Save，不然它就會儲存並且執行了。(不過Yaml檔異動也是會觸發CI機制，這個之後再說)

在Save and run按鈕下面有個Show assistant的按鈕，它會顯示一些可以選用的Tasks，也就是可以被加入在steps底下的項目，同時也是一些task的設定內容顯示的地方。(指的是UI顯示，不是yaml文字內容)

再回到前面兩個不同的Pipeline範本，Starter的範本內容最簡單，在steps中只有兩個script輸出了一些簡單的文字內容，通常這個範本就是被拿來當作空白的Yaml來使用，通常刪掉兩個script之後，會透過Show assistant點開之後所列出的Tasks，選擇適合的Task項目之後再進行調整。

從.NET Desktop的範本中則是可以看到稍微進階的一些內容，我們來一一拆解：

trigger:
- master

trigger指的是CI的觸發程序，master指的是當master這個Branch的內容有異動的時候就會觸發這個Pipeline，所以上面的Save儲存Pipeline Yaml檔，仍然會因為Yaml檔在Branch中被異動了而觸發Pipeline，所以如果要停用trigger不讓它觸發，就將master改為none就行。

trigger改為none之後就停用了CI，變成手動執行的一個Pipeline，這在初期建置Pipeline的時候可以避免Pipeline一直被觸發，等到Pipeline都設定好也試過都沒問題之後，再回頭來調整Trigger就行。後面的文章還會提到Yaml以外的Trigger設定方式。

pool:
  vmImage: 'windows-latest'

這裡的pool指的是執行的agent pool，vmImage指的是使用的VM映像檔，從上面的圖可以看到兩個不同的範本分別是選用windows-latest與ubuntu-latest。

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

variables則是定義在Pipeline中可以使用的變數，之後的task裡面可以用「‘$(變數名稱)’」這樣的格式來取得內容。

steps:
- task: NuGetToolInstaller@1

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

- task: VSBuild@1
  inputs:
    solution: '$(solution)'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

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

最後就是steps包含Pipeline實際執行的步驟，每一個步驟都是一個task，透過前面的variables定義將設定的值帶入task中使用。

看到上面這些yaml內容，新手可能會覺得看似簡單卻又好像很困難…，我怎麼知道哪些task有哪些內容可以設定？難不成要邊看一大篇的文件邊設定嗎？

這部份Azure DevOps也有考慮到，也做了很人性化的設計，常用VS寫Code的人一定也很依賴Intellisence提供的提示，所以在這個畫面下，同樣也有類似的功能：

除了設定值的提示功能之外，其實還有一個地方可以更方便的操作設定：

每一個task上面都可以看到灰色的Settings文字，這個Settings其實是可以點擊的，當你點擊它之後，在右邊就會出現這個task可以設定的屬性內容，從圖上可以看到有些屬性中有設定了內容，但是在yaml檔案文字中卻沒有出現，代表是task該屬性的預設值，至於圖中yaml文字所設定的platform、configuration這兩個屬性，則是在編輯介面的最下面，捲動往下就可以看到它們了。

透過這兩種方式就可以很方便的設計出想要的Pipeline內容，其實相較其它的系統來說，實在是方便很多，也是我個人比較喜歡使用Azure DevOps的原因。

不知不覺又寫得有點長了，這一篇就先到這裡，我們下一篇再繼續吧！

原文連結泰克哪裡去