讓我們提高開發體驗

任務-自動佈署

昨天說到了我們使用hosted pipeline把專案編譯後，打包成可以佈署的產物。今天就要來把這包產物放到我們測試環境中，可以讓使用者進行測試的動作。

先進行環境的註冊

這邊要先暫停一下yaml的撰寫，因為我們要佈署之前，我們會先要把我們想要佈署的主機給註冊上來，好讓pipeline 可以把要部署的產物給放置到我們的主機上。

首先先按下create environment。

建立以vm為主的environment。

接下來這個畫面中，就會產生一組指令，裡面會包含臨時的Personal Access Token，拿著這組指令到你的vm主機上，打開powershell with administrator權限，來進行環境的註冊。

筆者因為測試環境沒有對所有internet環境都有連通，因此agnet是透過下載後，下指令安裝的。記得一定要用administrator 的權限開啟powershell。

註冊完後，就可以去看一下resources 裡面，就多了你剛剛註冊那台機器。
但是剛剛很蠢的用中文命名了，等等把名稱改一下。

繼續yaml 的撰寫，完成自動佈署

- stage: 'Dev' #這個階段我命名為Dev
  displayName: 'DevCD'
  dependsOn: 'Build'  #這意思是，接續在前一天寫的Build 這個Stage 後繼續進行
  variables:  #這邊我加了一個判斷，如果是pipeline_test branch，那我site variables 就命名為mysite_T
    ${{ if eq(variables['build.sourceBranchName'], 'pipeline_test') }}:
      site: mysite_T
    ${{ else }}:
      site: mysite

  jobs:
    - deployment: 'VM_SIT'  
      displayName: 'VM SIT Deployment'
      workspace:
        clean: all
      environment:
        name: 'VM_SIT' #這裡則是我要佈署到的VM名稱，改成VM_SIT
        resourceType: VirtualMachine
      strategy:
        runOnce:
          deploy:
            steps:
              - task: printAllVariables@1 #習慣性印出所有變數
                displayName: 'Print all variables'
              - task: DownloadBuildArtifacts@1 #下載pipeline artifact
                inputs:
                  buildType: 'current'
                  downloadType: 'specific'
                  downloadPath: '$(System.ArtifactsDirectory)\$(Build.BuildId)\'
                  cleanDestinationFolder: true
              - task: ExtractFiles@1 #解壓縮
                inputs:
                  archiveFilePatterns: '$(System.ArtifactsDirectory)\$(Build.BuildId)\drop\$(Build.BuildId).zip'
                  destinationFolder: '$(System.DefaultWorkingDirectory)\$(Build.BuildId)\publish'
                  cleanDestinationFolder: true
                  overwriteExistingFiles: false

              - task: IISWebAppDeploymentOnMachineGroup@0 #這裡去跟IIS溝通，佈署到對應的site
                inputs:
                  WebSiteName: 'Default Web Site'
                  VirtualApplication: $(site)
                  Package: '$(System.DefaultWorkingDirectory)\$(Build.BuildId)\publish'
                  TakeAppOfflineFlag: true

• Stage：Dev－這階段我取名為Dev。
• dependsOn：Build－這裡則是指接續在Build 這個Stage 繼續進行。
• variables： 這邊我下了一個巧思，那就是如果是pipeline_test的branch的變更，變數後面就叫做site_T，不然就是正常叫做site。這邊是為了Ops在驗證自己的pipeline的時候，不要打擾到Dev的開發進度，因此在這裡做的事情就不會影響到開發人員的Cicd。
  • Job
    • environment
      • name:VM_SIT－這裡則是指我要佈署到這個資源去。
    • strategy
      • runOnce －只跑一次。
        • deploy
          • steps
            • task:printAllVariables－印出所有變數(這是一個外部套件)。
            • task:DownloadBuildArtifacts－下載這一個pipeline之前編譯出來的artifact。
            • task:ExtractFiles －解壓縮下載下來的檔案。
            • task:IISWebAppDeploymentOnMachineGroup－跟IIS溝通，佈署到被指定的位置去。

再來就是看成果的時候，當開發人員完成他的程式開發，PR進入source code 中，develop branch時，pipeline就會被觸發如下：


然後下面的細節可以看到，現在一共有兩個階段了，分別是Build and DevCD。另外要補充的是，下面紅框圈起來的部分，會發現到當mysite develop這個 branch被更新的時候，pipeline 的main branch被觸發，去抓到main上面對應的yaml檔案。

這裡有個雷

如果要跨repo 的branch 更新被觸發pipeline，是無法指定被觸發的pipeline repo 的branch的，一定要是預設分支。

當時搞了很久，因為pipeline還在開發中，所以一直沒有併入main branch。那時後就拿source code的develop branch 不斷驗證，就是不會被觸發，一度都快想要去開bug了。最後重新一個字一個字的K原廠文件，才發現他有寫一句：

如果變更任何其他存放庫資源會觸發管線，則會使用 來自存放庫預設分支 的 self 最新版本 YAML。 查看管線中的多個存放庫

這條也搞了一整個早上才搞定，有些雷就是要踩過一次，才會知道問題在哪。另外，這也驗證了我之前的想法大方向應該沒錯，在Day 10 的時候我說過，yaml這類型檔案，筆者是把他視為設定檔，不應該使用不同branch策略去進行管理的。而微軟的多repo設計，如果我想要把設定檔進行多個branch去進行策略管理，看起來也是無法做到的。

那個CICD終於可以開始讓開發人員在開發階段，更流暢的進行開發了