前言

Trigger (觸發器) 是 Pipeline/Release Pipeline 重要的功能，使用得宜的話，使用者可以專於自己本身的工作，而不需要持續檢視與手動執行 Pipeline 執行狀況，有效提升 IT 人員生產力。下面幾個案例提供參考

1. 合併入重要或多人共同維護分支時觸發，確保應用程式可以成功建置。早期工作曾遇到同事請假趕下班，將無法建置程式碼合併回 Dev 分支，另一位同事從 Dev 建立其他分支進行開發工作時發現無法建置，多花了2小時檢視程式碼並修復問題。
2. 建立 Pull Request 觸發並進行驗證，除了保證此次提交是可以成功建置，也確定合併後不會影響到重要分支
3. 在部署至 Production 前一晚或前一個假日自動觸發。避免部署前耗費人力與大量時間確認整合測試、壓力測試是否通過。離峰或非上班時間執行複雜繁瑣的 Pipeline 比較不會因為資源不足而需要等待。

上述情境只是基本的運用，但也並非大量設定 Trigger 就是好事，即使你有大量的 Agent (代理程式)，Azure DevOps Parallel Job 是需要費用的。或許有的人會說這筆費用對於多數企業是可以接受的，但其主要精神是拆分成部分工作並在離峰時間執行是重要的，這個時候成本是一回事，主要是執行效率。

依據過去顧問經驗，許多大型組織忽視拆分成部分工作並在離峰時間執行工作，且不願意投入資源做這件事情 - 日益龐大的 Pipeline 會造成很多問題

Trigger 介紹

Build Pipeline Trigger

在這篇文章我們主要討論 Continuous Integration Trigger 與 Scheduled Trigger，主要原因在於這兩個觸發功能有些細節設定可以有效提升生產力，其餘 Trigger 就簡易說明，讀者大概知道是什麼就好。Build Pipeline Trigger 可以分成下列幾種類型：

• Manual: 使用者手動執行，不會自動觸發 Pipeline
• Continuous integration: 推送變更至 Repo 後自動觸發 Pipeline
• Scheduled: 指定時間觸發 Pipeline
• Pull request validation:
• Build completion: 當上游相依 Build 改變時觸發新的 Build

如果你要停止 Trigger，可以參考下列設定

trigger: none

Continuous Integration Trigger

Continuous Integration Trigger 可以透過 Branch、Batch changes 與 Path filters 設定，避免因使用者大量推送變更至儲存庫時觸發 Pipeline，導致有限資源被耗盡造成 CI 排隊等待，進而影響其他重要工作。在有限的資源下，通常會建議設定主要分支與指令路徑，在資源充裕或此 CI 流程執行快速的情況下，才不反對包含全部分支。下面為設定範例。

trigger:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs

Batch (批次) 設定在團隊成員經常上傳變更也相當有效，當 Pipeline 正在執行時，Azure DevOp 會等到執行完成，然後啟動另一個執行，並執行尚未建置的所有變更，而不會一次小變更就執行一個 Pipeline，是非常推薦使用的功能。 下面為設定範例。

trigger:
  batch: true
  branches:
    include:
    - main

若你在 CI Pipeline 流程中有進行部署行為，建議不要啟動此設定

Scheduled Trigger

排程觸發器讓 Pipeline 有更多應用，除了前言所提到的可以在離峰時間執行複雜且冗長 CI 流程，更可以透過此功能做自動化工作，如：定期清理伺服器資訊、定期備份或同步資料 - 這讓 Pipeline 能做的不止是 CI 相關工作。其設定說明如下：

schedules:
- cron: string # cron 格式 (UTC 時間! 非常重要)
  displayName: string # 顯示名稱
  branches:
    include: [ string ] # 包含哪個分支
    exclude: [ string ] # 不包含哪個分支
  always: boolean # 若設定為 false，則程式碼有變更才執行；若為 true，則無視程式碼是否有變更
  batch: boolean # 若前一個排程 Pipeline 正在執行，是否要執行新的 Pipeline

always 設定相當重要，也是被問過最多問題的設定 (為什麼我的 Scheduled Trigger 沒有執行?)

 
其設定範例如下：

schedules:
- cron: '0 0 * * *'
  displayName: Daily midnight build
  branches:
    include:
    - main

另一種設定方式是透過 UI 介面，這也是需多使用者最容易混淆的地方，容易弄錯的地方包含

1. 我用的是 YAML 不是傳統編輯器，有 UI 設定嗎?
2. 使用 YAML 作為 Pipeline 工具時，設定功能在那裡?
3. UI 與 YAML 內都設定排程，不會衝突嗎?

實際上是有 UI 設定，其功能在編輯 YAML 畫面，點選右上角 ... 按鈕，選擇 Trigger。但要注意，UI 設定優先權高於在 YAML 內設定，一旦設定 UI Trigger， YAML 內的排程設定即無效。

Relese Pipeline Trigger

在這篇文章只簡單說明 Relese Pipeline Trigger 類型，就不多做描述與說明如何設定。主要原因就目前個人經驗，仍無法提供最佳實踐，也請讀者見諒。其類型可以分成下列幾種：

• Continuous deployment triggers: Azure Pipelines 在檢測到新 Artifact 可用時自動建新 Release
  目前僅適用於 Git 的來源
• Scheduled release triggers: 在特定時間建立和啟動 Release
• Pull request triggers: 設定 Pull Request trigger。Pull Request 上傳新版本的 Artifact 時建立新的 Release

Release Pipeline Trigger 也與 Build Pipeline Trigger 不同，是透過使用者介面進行設定。使用者可以在...

1. Artifact 設定 Continuous deployment trigger
2. Pre-deployment conditions 設定 Scheduled release trigger 與 Pull request trigger
3. Post-deployment conditions 設定 Auto-redeploy trigger