GitHub Code Quality 導入與趨勢追蹤：active committers、AI credits

Code Quality 實際包含哪些分析#

GitHub Code Quality 會在 pull request 與 default branch 提供結果。規則型分析使用 CodeQL，AI-powered analysis 則補充規則未涵蓋的問題；兩者的結果與可用語言範圍不要混為同一套保證。

GitHub 文件列出的 CodeQL 規則型分析語言包含 C#、Go、Java、JavaScript、Python、Ruby 與 TypeScript。AI-powered analysis 的涵蓋範圍可能更廣，但不能因此把 AI finding 當成所有語言都具有相同深度的靜態分析。

Trends 看到的是變化，不是單一品質分數#

Organization-level Code Quality dashboard 的 Trends tab 會把 open findings 依日期區間整理成趨勢。GitHub 目前提供 7、14、30 天的範圍，可以依 health score 或 severity 分組，並同時顯示目前 open findings 總數與區間開始到現在的 net change。

它還提供兩張 repository 表格：哪些 repository 改善最多，以及哪些 repository 需要支援。圖表與表格會套用 dashboard 上的 repository filters，因此可以先縮小到某個團隊、產品線或 repository 集合，再判讀變化來源。這讓 Trends 適合回答「哪裡在變差、哪裡正在改善」，但不該被解讀成單一的團隊品質排名。

這項能力的前提仍是 organization 已啟用 Code Quality，並使用 GitHub Team 或 GitHub Enterprise Cloud；GitHub Enterprise Server 不在支援範圍。Organization owner 能看到所有已啟用 repository 的資料，其他成員則受限於自己有權查看的 Code Quality findings，官方文件也對可見 repository 數量設有上限。若你要追蹤長期趨勢，先記錄 dashboard 的範圍、權限與啟用清單，避免把「看不到」誤認成「沒有 findings」。

可以把 Trends 放進 pilot 的驗收流程：先保存一個 7 天或 14 天基準，再對照 open findings、health score、repository filter 和實際 PR 修補。Code Quality 的 Trends 和 default setup 的中央 CodeQL 設定 是兩個不同層次；前者觀察結果如何變化，後者控制掃描設定如何套用。

先算清楚三種成本#

GitHub Changelog 將 Code Quality 描述為獨立的付費產品，並列出三類成本：

1. 授權費：每位 active committer 每月 $10。active committer 是在啟用 Code Quality 的 repository 推送過 commit，且時間落在最近 90 天的人；同一位 committer 在組織內只計一次，bot account 不收費。
2. AI 用量：AI-assisted detection 與 Copilot Autofix 依 usage-based billing 使用 GitHub AI credits；不需要另外擁有 GitHub Copilot 訂閱才能使用這些 Code Quality 能力。
3. 分析計算：deterministic CodeQL analysis 會使用 GitHub Actions minutes，GitHub-hosted 與 self-hosted runner 都可支援，但 runner 成本與並行限制仍要自行評估。

這三筆要分開記錄。active committer 數量是授權基礎，AI credits 是模型相關用量，Actions minutes 則是分析執行資源；用一個「每個 PR 平均成本」欄位把它們全部相加，會讓後續排查變得困難。

Enablement 先用小範圍 pilot#

Code Quality 的控制面可分 enterprise、organization 與 repository 三層。建議先採一個可以回溯的 pilot：

官方文件支援 organization-wide enablement、organization dashboard 與 API；這些能力適合在 pilot 通過後使用，不代表一開始就要對整個 organization 全開。先保留 selected repositories，較容易辨認新增的 finding、費用與 Actions 用量從哪裡來。

Quality gate 不要第一天就阻擋所有 PR#

Code Quality 的 rulesets 可以設定 quality 與 coverage threshold，也有 evaluate mode 讓團隊先觀察結果。實務上可以採下面順序：

1. 先讓 findings 出現在 PR，確認嚴重度與修補建議是否適合團隊程式碼。
2. 將既有技術債與新引入的問題分開；不要因為舊 repository 一次出現大量 finding，就直接阻擋所有新 PR。
3. 先對單一高影響條件設 evaluate，例如 coverage 不得比 default branch 下降。
4. 等測試、例外與誤報處理成熟後，再讓 ruleset 對特定 PR 阻擋 merge。

Copilot Autofix 只能提供待 review 的修改建議，不能取代測試、PR review 或 branch protection。若團隊也在追蹤 Copilot 的 PR 活動，可以參考 repository 指標與品質判斷的分界，不要把 finding 數、merge 數或 AI 使用量直接當成品質分數。

GA 導入前的最後檢查#

• 列出要啟用 Code Quality 的 repository、語言與 active committer 估算。
• 確認 enterprise、organization、repository 三層各由誰負責開關。
• 將 AI credits 與 Actions minutes 放進不同的預算或告警維度。
• 確認測試能輸出 Cobertura XML，且 coverage 的基準分支定義清楚。
• 用 evaluate mode 跑一個完整 PR 週期，再決定是否阻擋 merge。
• 在 organization dashboard 保存 Trends 的初始日期區間、repository filter 與 open findings，讓後續比較有固定邊界。
• 為 preview 時期已開啟的 repository 重新檢查啟用範圍，因為 GA 後已開始計費。

Code Quality 的價值在於把品質檢查放進既有 PR 流程，並讓團隊能觀察 findings 的變化；導入成功的條件是成本、finding、測試、趨勢範圍與審查責任都能被分開追蹤。先小範圍啟用，再把通過驗證的門檻擴大，會比把 GA 或 Trends 當成全組織自動開關更容易維護。

常見問題#