GitHub Code Quality GA 怎麼導入？先算 active committers、AI credits 與 Actions
GitHub Code Quality 在 2026 年 7 月 20 日正式推出後，不再只是可以免費試用的 public preview。它現在可在 GitHub Team 與 GitHub Enterprise Cloud 使用，並把 CodeQL 的規則分析、AI-powered analysis、Copilot Autofix、coverage 與 rulesets 放在同一個品質流程裡。
導入前最該先算的不是「能不能抓到更多問題」，而是哪些 repository 要開、哪些人會被算作 active committer，以及 AI credits 和 GitHub Actions minutes 要由誰監控。GitHub Enterprise Server 在這次 GA 時仍不在支援範圍。
Code Quality 實際包含哪些分析
GitHub Code Quality 會在 pull request 與 default branch 提供結果。規則型分析使用 CodeQL，AI-powered analysis 則補充規則未涵蓋的問題；兩者的結果與可用語言範圍不要混為同一套保證。
| 能力 | 主要輸出 | 導入時要問 |
|---|---|---|
| CodeQL quality analysis | reliability、maintainability finding | 目前的語言與 Actions runner 是否支援 |
| AI-powered analysis | PR 或近期變更的 AI findings | 是否允許消耗 AI credits，誰 review 結果 |
| Copilot Autofix | 可供人工 review 的修補建議 | 修補是否一定經過 PR 與測試 |
| Coverage | PR 上的 Cobertura coverage 資料 | 既有測試是否能產出正確格式 |
| Rulesets | quality 或 coverage threshold | 先 evaluate 還是直接阻擋 merge |
GitHub 文件列出的 CodeQL 規則型分析語言包含 C#、Go、Java、JavaScript、Python、Ruby 與 TypeScript。AI-powered analysis 的涵蓋範圍可能更廣，但不能因此把 AI finding 當成所有語言都具有相同深度的靜態分析。
先算清楚三種成本
GitHub Changelog 將 Code Quality 描述為獨立的付費產品，並列出三類成本：
- 授權費：每位 active committer 每月 $10。active committer 是在啟用 Code Quality 的 repository 推送過 commit，且時間落在最近 90 天的人；同一位 committer 在組織內只計一次，bot account 不收費。
- AI 用量：AI-assisted detection 與 Copilot Autofix 依 usage-based billing 使用 GitHub AI credits；不需要另外擁有 GitHub Copilot 訂閱才能使用這些 Code Quality 能力。
- 分析計算：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：
| 階段 | 設定 | 驗收條件 |
|---|---|---|
| 1. Enterprise | 允許 enterprise 使用 Code Quality | 確認合約、帳務與 GitHub Actions 政策 |
| 2. Organization | 只開 selected repositories 或 matching filter | 列出 pilot repo 與負責團隊 |
| 3. Repository | 開啟 Code Quality、等待初次掃描 | 對照 PR finding、default branch 與 Actions run |
| 4. Ruleset | 先用 evaluate mode | 收集誤報、例外與 coverage 缺口 |
| 5. 擴大範圍 | 調整門檻後再套用更多 repository | 有明確的 rollback 與例外流程 |
官方文件支援 organization-wide enablement、organization dashboard 與 API；這些能力適合在 pilot 通過後使用，不代表一開始就要對整個 organization 全開。先保留 selected repositories，較容易辨認新增的 finding、費用與 Actions 用量從哪裡來。
Quality gate 不要第一天就阻擋所有 PR
Code Quality 的 rulesets 可以設定 quality 與 coverage threshold，也有 evaluate mode 讓團隊先觀察結果。實務上可以採下面順序：
- 先讓 findings 出現在 PR，確認嚴重度與修補建議是否適合團隊程式碼。
- 將既有技術債與新引入的問題分開；不要因為舊 repository 一次出現大量 finding，就直接阻擋所有新 PR。
- 先對單一高影響條件設 evaluate，例如 coverage 不得比 default branch 下降。
- 等測試、例外與誤報處理成熟後，再讓 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。
- 為 preview 時期已開啟的 repository 重新檢查啟用範圍，因為 GA 後已開始計費。
Code Quality 的價值在於把品質檢查放進既有 PR 流程，但導入成功的條件是成本、finding、測試與審查責任都能被分開追蹤。先小範圍啟用，再把通過驗證的門檻擴大，會比把 GA 當成全組織自動開關更容易維護。
常見問題
Q: GitHub Code Quality 需要 GitHub Copilot 或 Advanced Security 訂閱嗎？
A: Code Quality 是獨立的付費產品，不等同於 GitHub Advanced Security，也不要求 GitHub Copilot 訂閱才能使用 AI-powered detection 或 Copilot Autofix。不過，若要把修補工作委派給 Copilot cloud agent，仍需要符合該功能的 Copilot 資格。
Q: active committer 是每個 repository 各算一次嗎？
A: GitHub 公告的計算方式是：在啟用 Code Quality 的 repository 於最近 90 天推送 commit 的人會被視為 active committer；同一位 committer 在同一組織內只計一次，bot account 不收費。
Q: Code Quality 的 ruleset 可以一開始就阻擋 PR 嗎？
A: 可以設定 quality 或 coverage threshold，但導入時建議先使用 evaluate mode，先觀察 findings、誤報、既有技術債與測試輸出。等團隊能處理例外與修補流程後，再讓門檻阻擋 merge。
參考資料：
GitHub Changelog：GitHub Code Quality is now generally available
回報錯字、失效連結，或告訴我你想看的延伸主題。