Team Foundation Server 2010 引入 **Gated Check-in** 機制：程式碼必須通過 Team Build 編譯 (含測試) 才能真正提交至版控，從源頭杜爛「爛代碼污染主分支」問題。本文完整解析觸發條件、三階段流程、Build Definition 設定、失敗處理與 Unshelve 協作修復。
Team Build 觸發條件對照
| 觸發模式 | 行為 | 影響 Check-in |
|---|
| Manual | 手動排隊建置 | 無 |
| Continuous Integration (CI) | 每次 Check-in 觸發建置 | **不阻擋** Check-in (建置失敗不影響已提交程式碼) |
| Rolling Builds | 建置完成後固定間隔自動觸發 | 不阻擋 |
| Gated Check-in | **建置成功才允許提交** | **阻擋**失敗提交 |
| Scheduled | 排程時間建置 | 不阻擋 |
Gated Check-in 三階段流程
- Shelve (擱置)：開發者發起 Check-in → TFS 將變更建立 **Shelveset** (相當於私有分支) 存放伺服器，**不寫入版控歷史**。
- Build (建置驗證)：Team Build 代理取得 Shelveset 內容 → 在建置代理機器還原工作區 → 執行完整建置流程 (編譯、測試、程式碼分析等)。
- Commit / Discard：
- 建置 **成功** → 自動將 Shelveset 內容 **Check-in 至版控** (成為正式變更集)。
- 建置 **失敗** → **拒絕提交**，Shelveset 保留在伺服器，開發者收到詳細失敗報告。
Build Definition 關鍵設定
測試執行策略
- Run Tests：可選擇不執行測試 (加快 Gated 回饋)、僅執行單元測試、或完整測試組合。
- Fail Build on Test Failure：啟用後，**任何測試失敗即判定建置失敗**，Check-in 被拒。建議 Gated Check-in **啟用此選項**，確保門檻效力。
- 策略建議：
- Gated Check-in：必跑單元測試 + 靜態分析，追求 <5 分鐘回饋。
- Nightly Build：完整測試套件 + 整合測試 + 部署驗證，耗時較長無妨。
Check-in 體驗與失敗處理
發起 Gated Check-in
- Visual Studio Check-in 對話框顯示「Build Changes for Gated Check-in」確認。
- 預設強制建置，**需高權限 (Administer build) 才可選擇「Don't build」略過**，一般不建議略過。
建置失敗：TFS 拒絕提交
- 錯誤訊息詳細列出：
7/8 test(s) passed, 1 failed、Code Coverage: 33%、受影響測試清單。
- 程式碼 **未寫入版控**，保留為伺服器端 Shelveset。
協作修復：Unshelve 取得被擱置變更
- 同事點擊失敗通知中的 Unshelve Changes 連結。
- Visual Studio 開啟 Unshelve 視窗，選取該 Shelveset → Unshelve 至本地工作區。
- 修復測試失敗 → 重新發起 Gated Check-in → 通過 → 原作者 Shelveset 自動提交。
💡 此機制完美支援「同儕審查 + 協作修復」流程，無需手動傳遞 Patch 檔。
建置成功：Build Notification 即時通知與工作區同步
- 安裝 Build Notification 工具 (VS 2010 Tools 選單)
- 設定 TFS 連線、專案、關注的 Build Definition、Started/Finished 事件通知
建置完成通知
- 彈出視窗提示「變更已提交」，提侑 Reconcile (同步至本地) 或 Ignore。
Reconcile 相當於 Get Latest，將最新版控內容更新至工作區。
Gated Check-in 核心價值總結
| 痛點 | Gated Check-in 解決 |
|---|
| 爛代碼污染主分支，導致後續所有 CI 失敗 | **源頭攔截**：未通過建置絕不入庫 |
| 修復建置失敗耗時長，阻塞團隊進度 | **隔離驗證**：失敗僅影響提交者，他人不受影響 |
| 測試常被忽略，品質無保障 | **強制門檻**：Fail Build on Test Failure = 必須過測試才能提交 |
| 協作修復缺乏工具支援 | **Unshelve 一鍵取得** 失敗者變更，即時協作 |
避坑指南
- 建置代理效能：Gated Check-in 高頻觸發，**建置代理機器需足夠 CPU/記憶體/SSD**，否則排隊等待時間過長挫傷開發體驗。
- 測試分層：Gated 僅跑 **快速單元測試** (目標 <5 min)；整合/效能/UI 測試放 Nightly/Weekly。
- 大型專案：考慮 **分模組 Gated** (各模組獨立 Build Definition)，避免單一龐大建置成為瓶頸。
- 權限控制：嚴格限制「Administer build」權限，防止濫用「Don't build」繞過門檻。
總結
Team Build 2010 Gated Check-in 以 **Shelve 隔離 + 自動建置驗證 + 通過才提交** 三階段流程，從流程層面解決「爛代碼入庫」的經典難題。配合 **測試分層策略**、**Build Notification 即時感知**、**Unshelve 協作修復**，構成現代敏捷團隊 **持續交付品質閘道** 的核心基石。
