前言

身為近年來的開發工程師，你一定有遇過在自己電腦上建置好好的，當推送至 CI 工具時卻出現建置錯誤情況。當新手工程師或沒有建置過持續整合流程經驗的同仁，可能就會感受到壓力並直白地說 “這程式在我的電腦事建置成功的” 或 “我程式碼沒有調整” …等話語。越大組織、分工越細的團隊越容易發生這種事。實際上，查詢 CI Pipeline 發生什麼事情並不是可怕的事情，如同對程式進行測試與偵錯一樣，任何人都可以慢慢地發現問題。透過解決這些問題，工程師會對撰寫程式與系統有更進一步的了解。

本篇文章將分享幾個實用技巧，讓你遇到類似情況時可以快速發現問題並進行排除。

檢視日誌與開啟診斷日誌 (diagnostic logs)

詳細檢視 Azure Pipeline 是一件重要的事情，經驗較匱乏的工程師可能會有找不到或錯誤解讀情況發生，耐著性子解讀錯誤訊息並找到解決方法是很重要的。另外，大多數 CI 工具會提供診斷日誌，詳細列出持續整合過程中所使用的變數與詳細錯誤訊息，可以提供 IT 團隊更多資訊，快速找到根本問題`

建議：不要每次 CI 皆開起診斷日誌，除了在平時產生過多訊息可能變成雜訊，也會造成執行時間較久情況發生

若內容過多難以閱讀，你也可以下載下來透過相關工具快速搜尋與比對

執行 Azure Pipeline 時，可以勾選 enable diagnostic，即會開啟診斷日誌功能

確認本地端電腦是否能重現相同問題

確認開發環境與 Azure Pipelin 是否能夠有接近的設定，以重現相同問題。正常情況下，在自己開發環境上若能重現，處理的成本是最低的。雖然持續整合環境相當複雜 (像是安全掃描或進階的測試)，無法完整地在本地環境重現，但透過縮減範圍 (如執行建置或單元測試) 方式嘗試在本地端重現是不錯的方式。

正常情況下， CI 會使用乾淨的環境排除套件相依或開發環境設定導致建置失敗，有些情況是本地電腦的快取或環境設定所造成。清除快取或妥善的環境設定(如 git ignore)可以增加生產力，並避免影響團隊。

找到上一次成功的執行，比對程式碼與 YAML 差異

Azure Pipeline 每次執行皆與版本管理連結，你能清楚知道這次的執行包含了那些修改。當這次建置錯誤發生，重新執行上一次成功 Commit 可以縮小問題範圍 (可以排除 Azure Pipeline 或 Agent 問題)，並透過兩次內容差異，更快速發現可能的根本問題。

在執行 Azure Pipeline 時，你可以選擇 Branch 與輸入 Commit ID，藉此方式重現上一次成功的執行。

啟用 HTTP Trace

若 Azure Pipeline 執行過程中有 HTTP 請求相關工作，可以啟用內建的 HTTP Trace，列出詳細資訊以確認問題。使用時要注意，可能會列印出敏感資訊，記得偵錯結束後記得關閉。

在 Pipeline YAML 檔案內加入變數 VSTS_AGENT_HTTPTRACE=true 即可。

Windows:
    set VSTS_AGENT_HTTPTRACE=true

macOS/Linux:
    export VSTS_AGENT_HTTPTRACE=true