CI 管線結果桑基圖：由觸發到失敗成因
追蹤管線運行由觸發到結果，以及每次失敗嘅成因：不穩定測試、真正退化、設定同環境。換上你自己嘅 CI 紀錄。
CI 管線桑基圖顯示建置按觸發方式點樣收場，以及點解失敗。佢將有意義嘅失敗（退化）同冇意義嘅失敗（不穩定測試）分開。
例子有 900 次管線運行，來自三種觸發：推送到主分支、拉取請求同夜間建置。760 次通過所有階段，140 次失敗，分別喺建置（37）、測試（96）或部署（7）。最後一欄列出成因：不穩定測試、真正退化、程式碼錯誤、依賴項或設定，以及測試環境。
通過率會掩蓋組成。喺例子入面，96 次測試失敗有 35 次係不穩定，呢個係測試套件嘅信任問題；45 次係真正退化，即係管線正常運作。計數單位係運行而唔係提交，所以重試也算一次運行。想睇之前嘅審查階段，可以睇 /yue/sankey/pull-request-review-flow；更完整嘅流程，可以睇 /yue/guides/如何找出軟件發佈流程樽頸。
點樣閱讀呢個圖表
- 900 次運行入面，760 次（84%）通過所有階段；140 次（16%）失敗。
- 測試係最常見嘅失敗位置：140 次失敗入面有 96 次（69%）。
- 35 次失敗係不穩定測試，佔全部失敗 25%；45 次係真正退化。
- 拉取請求運行通過率 82%（500 次入面有 410 次），主分支係 90%（300 次入面有 270 次）。
圖表背後嘅資料
虛構數字，只作說明，並非任何真實公司、團隊或系統嘅資料。
| 來源 | 目標 | 數量（次管線運行） |
|---|---|---|
| 推送到主分支 | 通過所有階段 | 270 |
| 推送到主分支 | 建置階段失敗 | 8 |
| 推送到主分支 | 測試階段失敗 | 17 |
| 推送到主分支 | 部署階段失敗 | 5 |
| 拉取請求 | 通過所有階段 | 410 |
| 拉取請求 | 建置階段失敗 | 25 |
| 拉取請求 | 測試階段失敗 | 65 |
| 夜間建置 | 通過所有階段 | 80 |
| 夜間建置 | 建置階段失敗 | 4 |
| 夜間建置 | 測試階段失敗 | 14 |
| 夜間建置 | 部署階段失敗 | 2 |
| 建置階段失敗 | 程式碼錯誤 | 15 |
| 建置階段失敗 | 依賴項或設定 | 22 |
| 測試階段失敗 | 不穩定測試 | 35 |
| 測試階段失敗 | 真正退化 | 45 |
| 測試階段失敗 | 環境 | 16 |
| 部署階段失敗 | 依賴項或設定 | 3 |
| 部署階段失敗 | 環境 | 4 |
同樣嘅資料（CSV）
source,target,value
推送到主分支,通過所有階段,270
推送到主分支,建置階段失敗,8
推送到主分支,測試階段失敗,17
推送到主分支,部署階段失敗,5
拉取請求,通過所有階段,410
拉取請求,建置階段失敗,25
拉取請求,測試階段失敗,65
夜間建置,通過所有階段,80
夜間建置,建置階段失敗,4
夜間建置,測試階段失敗,14
夜間建置,部署階段失敗,2
建置階段失敗,程式碼錯誤,15
建置階段失敗,依賴項或設定,22
測試階段失敗,不穩定測試,35
測試階段失敗,真正退化,45
測試階段失敗,環境,16
部署階段失敗,依賴項或設定,3
部署階段失敗,環境,4運作方式
匯出一個時段嘅管線運行
包括觸發方式、首個失敗階段同結果。重新運行要當作獨立運行。
標記每次失敗嘅成因
用簡短清單：不穩定、退化、程式碼錯誤、設定、環境。冇成因嘅失敗歸入「未知」，值得顯示出嚟。
計算觸發、結果到成因
每次運行按首個失敗階段只計一次。
檢查平衡
每個失敗階段流出嘅運行數必須等於流入。「通過」喺第二欄完結。
常見問題
點樣分辨不穩定測試同退化？
常見做法係：同一個測試失敗之後，喺程式碼冇改動下重試就通過，即係不穩定。用你團隊現有嘅規則，並每個時段都保持一致。
點解數運行而唔係提交？
運行係 CI 系統記錄嘅單位。如果想數提交，就按每個提交嘅最終結果只計一次，並喺資料說明入面講明。
編輯呢個 CI 管線桑基圖
將例子開成你自己嘅圖表，輸入你嘅管線數目。