發表文章

目前顯示的是 10月, 2018的文章

土炮 TFS Check-In Policy - 簽入時強制再使用本機 MSBuild 重建通過後才允許簽入

圖片
前言 最近在客戶端遇到一個需求,由於時常發生一種情況就是 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 的可