【把玩Azure DevOps】Day7 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的人一定也很依赖Intellisense提供的提示，所以在这个画面下，同样也有类似的功能：

除了设定值的提示功能之外，其实还有一个地方可以更方便的操作设定：

每一个task上面都可以看到灰色的Settings文字，这个Settings其实是可以点击的，当你点击它之後，在右边就会出现这个task可以设定的属性内容，从图上可以看到有些属性中有设定了内容，但是在yaml档案文字中却没有出现，代表是task该属性的预设值，至於图中yaml文字所设定的platform、configuration这两个属性，则是在编辑介面的最下面，卷动往下就可以看到它们了。

透过这两种方式就可以很方便的设计出想要的Pipeline内容，其实相较其它的系统来说，实在是方便很多，也是我个人比较喜欢使用Azure DevOps的原因。

不知不觉又写得有点长了，这一篇就先到这里，我们下一篇再继续吧！