前言

過去在微軟擔任現場工程師期間，到過許多公家機關、金融證卷與醫療資訊介紹 Azure DevOps，其中最受歡迎的莫過於 Azure Pipeline。理所當然，許多未接觸過持續整合與持續交付的組織對 Azure Pipeline 充滿幻想。有趣的是，依據個人經驗，多數政府機關建立持續整合與持續交付是基於資訊安全，而非要求頻繁交付；多數醫療機構通常建立部分自動化持續整合與交付而不自知，會質疑 Azure Pipeline 能帶來多大好處；而金融業對於持續整合與持續交付比較偏向原有書上理論。

一套軟體開發的實踐，不同產業不同解讀，那究竟什麼是 持續整合 (Continuous Integration) 和持續交付 (Continuous Delivery) 服務？

關於持續整合的描述，我們引用 Martian Fowler 的說明:

持續整合是一種軟體開發的實踐，讓團隊成員經常整合他們的工作，通常每個人至少每天進行一次到數次的整合。每次整合均透過自動化建置與測試進行驗證，以盡快檢測出整合錯誤。多數團隊發現此方法可以顯著減少整合問題，允許團隊更快速開發有凝聚力的軟體。

而 持續交付 是持續整合的延伸，雖然不適合所有人，但如果實作得宜，就像施展魔法一樣，可以省去很多麻煩事與心力。它非常依賴 Release Pipeline 內所有自動化的 elements 與 tasks。

無論哪一個行業，個人自始自終相信：軟體應始終處於隨時可以發佈至 Production 的狀態。

Azure Pipeline 介紹

Azure Pipeline 是功能齊全的持續整合和持續交付服務，適用於多數熱門程式語言與專案類型，有助於確保使用者可以隨時使用一致的且高品質的程式碼。在開始詳細介紹 Azure Pipeline 必須先了解依些基本觀念，如果先前你已經看過 Continuous Integration 或 Continuous Delivery 相關書籍，你可能會覺得這些專有名詞 (Pipeline, Task, Agent... etc.) 有點熟悉。下列提供一些常用關鍵字說明：

• Agent
  • 當建置或部署運行時，系統會開始一項或多項作業。 Agent (代理程式) 是一次執行一個建置或部署作業之可安 裝軟體。
• Artifact
  • 由建置發佈的檔案或 Package 的集合。 Artifact 可用於後續任務，例如發佈或部署
• Build
  • Pipeline 一次的執行。它收集與執行步驟相關的日誌和執行測試的結果。
• Deployment target
  • 部署目標是虛擬機、容器、Web 應用程序或用於託管正在開發的應用程序的任何服務。 在建置完成並執行測試後， Pipeline 可能會將應用程序部署到一個或多個部署目標.
• Job
  • 一個建置包含一個或多個 Job。 每個 Job 都在一個 Agent 上運行。 Job 代表一組 Step 的執行。 所有Step 在同一個 Agent 上一起執行。
• Pipeline
  • 定義您的應用程序的 CI 和 CD 過程。 它由稱為任務的 Steps 組成。 可以將其視為定義測試、和部署步驟如何運行的腳本。
• Release
  • 使用可視化設計器時，除了Build Pipeline 之外，您需要建立一個 Release Pipeline 。 Release 表示 Release Pipeline 一次執行。 它由多個階段的部署組成。
• Task
  • Task 是 Pipeline 的建置區塊。 例如， Build Pipeline 可能包含 Build 任務和測試任務。 Release Pipeline 由部署任務組成。 每個 Task 在管道中運行一個特定的作業.
• Trigger
  • 是設置來告訴管道何時執行的東西。 您可以將 Pipeline 配置為在推送到儲存庫時、在預定時間或在另一個 Build 完成時執行。 所有這些動作都稱為觸發器。

依據功能設定來說，Pipeline 用於建構 CI，Release Pipeline 建構 CD。但不同情境的可能單獨使用 Pipeline 或 Release Pipeline

雖然使用者可以在 Pipeline 建立交付工作，在 Release Pipeline 進行整合工作，但多數情況下建議 Pipeline 用於建構 CI，Release Pipeline 建構 CD，除了團隊比較不會混淆，也較能發揮其完整的功能

Pipeline

Pipeline 的設定可以分成兩種：視覺化設計工具與 YAML定義檔。目前普遍推薦使用方式是 YAML，雖然沒有視覺化工具直覺，但好處是定義檔案可以透過版本管理進行管理，並須透過 Pull Request 和分支構建策略中的程式審查來驗證您的更改，除了流程較為嚴謹，當修改發生問題時，因為有版本控制，您可以更輕鬆識別問題。簡單的設定流程如下圖：

Azure Pipeline 內提供多種樣板 (Template) 與工作 (Task)，適用於多平台 (Windows, Linux, MacOs)與支援多種程式語言，也提供多種單元測試框架，降低使用者自行撰寫/維護 Script 負擔。除此之外，Azure DevOps 提供市集讓使用者發佈或下載多種延伸套件，這也是為什麼到企業推薦平台會先推薦 Azure DevOps 與 GitHub 主因之一：強大且眾多的功能套件可以使用。

注意：市集雖然有許多企業/開發者提供自訂延伸工具可以使用，但盡可能選擇知名組織或評價良好的延伸工具，並在使用前檢視其原始碼，避免敏感資料洩漏事情發生

Release Pipeline

Release Pipelines 是 DevOps CI/CD 的基本元素，可幫助您的團隊以更快的速度和更低的風險持續向客戶交付軟體。您可以在多個階段完全自動化您的軟體的測試和交付，直至 Production，或者設置半自動化流程並獲得同意和依據需求進行部署。

什麼時間點你需要 Release Pipeline?

• 開發應用程式並需要定期將它們部署到任何平台、公共或私有雲服務或應用程式商店
• 使用持續整合 (CI) 系統並正在尋找成熟的持續交付管理或發佈系統。
• 需要追蹤發布的進度
• 需要控制部署流程
• 需要所有版本及其部署的審核歷史記錄

 
 
一個完整的 Release Pipeline 需要做下列的設定：

• 為要在各個階段部署的應用程式定義端點到端點發佈
• 為應用程式建立 Release Pipelines 來使用 Azure Pipelines 發布
• 指定Release Pipelines 的 artifacts
• Artifacts 是應用程序的可部署套件。 它通常是通過 CI 或 Build Pipelines 產生。 Azure Pipelines 版本可以部署由各種來源的 Artifacts ，例如 Azure Pipelines build、Jenkins 或 Team City
• 使用 Stage 定義 Release Pipelines ，並使用 Approvel 限制部署階段
• 使用 Job 和 Task 定義每個 Stage 的自動化流程
• 使用變數來概括您的自動化和 Trigger 來控制何時應該自動啟動部署

其他最佳實踐

隨著 Pipeline/Release Pipeline 越來越成熟，您可以考慮下列事項讓管理與維護更加容易：

1. 使用變數 (variables) 減少重複程式碼，提高可維護姓
2. 盡可能使用觸發 (trigger)，節省時間並專注在開發上
3. 建立樣板 (Template) 並讓 Pipeline 重複使用，取代複製備份 Pipeline