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

鳴人
·
·
IPFS
·

前一篇介紹了要用來作為建立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還可以看到更多範本如下圖:

Azure DevOps Pipeline提供的各種範本

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

.NET Desktop範本YAML內容

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

Starter pipelin範本YAML內容

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

Pipeline 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提供的提示,所以在這個畫面下,同樣也有類似的功能:

Yaml的Intellisence

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

Task的屬性編輯介面

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

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

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

原文連結泰克哪裡去

CC BY-NC-ND 2.0 授权

喜欢我的作品吗?别忘了给予支持与赞赏,让我知道在创作的路上有你陪伴,一起延续这份热忱!