Gelis 技術隨筆-部落格

前言 最近在客戶端遇到一個需求，由於時常發生一種情況就是 Developer 撰寫完程式碼簽入 TFS 時，總是會將無法編譯通過的程式碼簽入，通常，在直覺上想到的就是 TFS Build 的『閘道簽入』 透過閘道簽入可以做到『先提交程式碼』到後端 TFS 的 Build 主機，交由 Build 主機確認該程式碼可以建置通過，當然，一般來說，所謂的完整地 CI 必須經由 Build Server 建置通過 + Unit Test + Source Analysis 完成的才表示程式碼是可交付、且沒有問題，當然，流程上是沒有問題的！標準的 CI 確實是如此，但是…. 有另外的一個問題來了！因為，所謂的閘道簽入它還是將『無法編譯的程式碼』簽入到 TFS 中了，而且，熟悉 TFS 的應該都知道，Developer 還是可以選擇將『在本機保留我的暫止的變更』的勾勾消掉，甚至略過驗證組建… 所以，這根本還是無法達到客戶的需求，客戶雖然希望由 CI 機制通過、出去的程式碼才是標準、可運行的，但是，希望開發人員可以在本機先進行『建置』動作，並確認建置動作是 OK 沒有問題的！才開放讓開發人員簽入程式碼。 TFS Check-In Policy 而這時，客戶提了個需求，說：TFS 有沒有 Check-In Policy 是可以在 Client Visual Studio 端確認建置過才可簽入呢？就像是 StyleCop 可以在 Client 先掃過程式碼，確認符合團隊的 Coding Style 後才允許簽入。 聽到這需求後，我當下想了想，身為 Visual Studio 擴充套件開發魔人的我，寫過各式 VS Extensions 還上架了一個 MyORM Extension ，甚至還推出了『C# Project Templates』的線上課程，當然 VsPackage 是不同的，但是我也寫過 VsPackage，卻沒寫過 TFS Check-In Policy 這…他日恐遭人話柄 XD 需求分析： 使用 C# 撰寫一個 VS 擴充套件，就像 StyleCop 一樣，只是這個套件必須呼叫 Local 端的 MSBuild 進行專案的建置動作，如果建置不過，就不讓 Developer 簽入程式碼，並秀出錯誤訊息。 這個 Check-In Policy 也必須可以被包裝成 VSIX 的可...