讓我們來提高開發體驗

如同前面說的，我們先來幫開發人員在開發階段，可以不用再去打開遠端桌面連線，把自己電腦的東西往伺服器放了，而且也不用用電話或是email的方式去跟需求人員告知已經可以驗證了。

目標就是，只讓開發人員接觸到開發工具、Git以及Azure DevOps Service，電話out、email out。

任務 - 自動編譯

這次的用來作範例的，就是一個.net framework 4.8的網站，我們透過hosted pipeline 幫我們把程式碼丟上去進行編譯後，把產物打包回來。

讓我們來看看下面的yaml的分段解說。

# ASP.NET
# Build and test ASP.NET projects.
# Add steps that publish symbols, save build artifacts, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/apps/aspnet/build-aspnet-4


resources:
 repositories:
  - repository: mysite  
    type: git
    name: mysite/mysite #敘明我要抓source code 的repo
    ref: develop #敘明要抓develop這個branch 的head
    trigger:
      branches:
        include:
          - develop  #mysite 的develop branch 會發動
          - pipeline #mysite 的pipeline branch是給pipeline 這邊用來實驗的

trigger:
- pipeline_test #因為有Bug，所以限制pipeline repo的branch 除了main以外，都要帶pipeline的前綴

pool:
  vmImage: 'windows-latest'  #hosted pipeline要用的image

1. resources 區塊敘述了我這次要使用到的一些資源，包含了
   1. 這次要用的source code 的repo，mysite。
   2. 要抓取develop branch 的head。
   3. trigger 有兩個branch 在更新的時候會被觸發這條pipeline，名稱為：
      1. develop，開發人員使用的，他們更新這條pipeline的時後，會來抓取這個repo 的main的這一個yaml檔案進行自動化作業。
      2. pipeline，這是給ops使用，例如需要將編譯所需要的檔案進行微調整，或是要將config檔案進行一些處理使用。
2. trigger，這裡則是說在pipeline repo，如果是pipeline_test這個branch被更新的時候，就會被觸發。這邊剛剛好還挖到了一個微軟的Bug，所以暫時workaround以及做了註記，尚未到社群去回報。
3. pool，我這裡選擇在hosted pipeline使用 'windows-latest'最新版的image來進行。

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

stages:
- stage: 'Build'
  displayName: 'Build'
  jobs:
     - job: 
       steps:
        - checkout: mysite
        - task: printAllVariables@1  #習慣性把所有變數印出來
          displayName: 'Print all variables'
        - task: NuGetToolInstaller@1

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

        - task: VSBuild@1  # 編譯的作業
          inputs:
           solution: '$(solution)'
           msbuildArgs: '/p:DeployOnBuild=true /p:DeployOnBuild=true /p:PublishProfile=FolderProfile.pubxml'
           platform: '$(buildPlatform)'
           configuration: '$(buildConfiguration)'
        - task: ArchiveFiles@2 #將編譯後的產物，打包成zip
          displayName: '封存 $(Build.ArtifactStagingDirectory)\mysite'
          inputs:
            rootFolderOrFile: '$(Build.ArtifactStagingDirectory)\mysite'
            includeRootFolder: false
        - task: PublishBuildArtifacts@1 #將zip傳到pipeline artifact
          displayName: '發行成品: drop'
          inputs:
            PathtoPublish: '$(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip'

1. variables，把一些編譯或是restore會使用到的變數給獨立出來。
2. Stage：這裡我定義了這個階段叫做Build，而且顯示的名稱也叫做Build。
   1. Job and Steps
      1. checkout：把這次要用的source code 抓下來準備編譯，名稱為上面命名的mysite。
      2. task：printAllVariables，這是一個marketplace的套件，我習慣性會把所有的變數都印出來，好觀察過程。
      3. task：NuGetToolInstaller，安裝nuget tool。
      4. task：NuGetCommand，restore solution，將專案所需要的套件都還原回來。
      5. task：VSBuild，根據設定進行編譯的作業。
      6. task：ArchiveFiles，將編譯後的產物，打包成zip
      7. task：PublishBuildArtifacts，將zip傳到pipeline artifact

來看看成果

到此為止，我們一個CI Build的過程基本已經成形，我們把程式碼給進行編譯後，把產物丟到了pipeline artifact中，所以來看看跑起來的成果。

可以看到，撰寫的yaml 在hosted pipeline建置成功，同樣的解說一下：

• 最上面紅色圈起來的部分，代表者這個build有一個產物。
• 打開產物看，會發現有一個15.zip的產出物，共21MB。
• Job 執行成功，共花費5m 13s。
• 使用了兩個sources，分別是：
  • pipeline，專門用來撰寫yaml的repo。
  • mysite，用來儲存source code的repo。

今天寫很多了，明天再來寫 cd的部分。

寫yaml跟寫程式一樣，完成某件任務，都會有那種小小的成就感