TFS 2010 的 Gate Check-In 閘道簽入 使用時機
在 TFS 2010 的自動化建置時多了一個功能「閘道簽入 Gate Check-In 」的機制
這個功能對於 Configuration Manage 管理人員來說是個非常棒的事情
若團隊正在導入 Scrum / Agile 流程的話，或是看了 約耳的書 想要導入 持續整合
那麼一定要看一下這個。
大部分在講持續整合的相關文章中都會提到
每天大家下班的時候，無論程式碼是否寫完，都要把今天寫的程式碼做簽入。
晚上 Build Server 就會把大家的程式碼進行編譯，隔天就會跑出那些模組無法正常編譯成功的 Report。
但，在實務上這樣子做會遇到幾個管理上和協同開發的問題
程式碼寫到一半就簽入
基本上 50% 以上都是無法正常編譯，就算編譯通過功能肯定有問題 ( 當然啦！寫到一半嘛 )
通常台灣的團隊大家都是用共用同一個 分支，自已的程式碼有問題就算了
你難保別人在開發別的模組時，不會去取得最新的版本。這時別人可能會因為你簽入的程式碼而變得無法正常編譯
為了解決這個問題，還要再把剛剛取得最新版本的部分一個一個拿掉。
從管理角度來看，系統就會出現很多個 無效的 Change Set 。對於管理的時間成本自然而然就會增加不少所以只要是無法編譯 或是還沒有寫好的程式碼，還是比較建議不要簽入 或是 改用 「擱置」
是否有其他的方式可以達到每日簽入的效果？
對於版控管理非常落實的團隊可以發現，最主要的問題都是在於是否有做「分支管理 Branch Management」
只要把在開發不同的模組的工作區域隔離後，就可以要求大家每天簽入而不會影響到其他人。
每日簽入除了有備份的效果外，更重要是搭配「持續整合」可以每天了解到專案修改的情況 ( 修改的行數、整合性、測試通過率)
但，這個在台灣老闆的精兵策略後，在實務管理上相對的工 就會多很多。
所以回歸到基本面，我們要了解到自已的團隊開發流程再來決定。
ps.. 若是您的版控裡的程式碼沒有辦法取得最新的程式碼後就編譯成功，那麼您有必要認真地好好思考要依有限資源的情況下如何做調整。
那麼，閘道簽入是什麼？
它主要是解決「連續整合」( 持續整合 continuous integration ) 沒有辦法達到的
要用「持續整合」的功能，就代表程式碼一定要簽入到版控中才有辦法做
但，是否可以讓 Build 先執行 「建置」、「測試」、「分析」再決定是否可以簽入？
以避免有無謂的 Change Set
簡單來說它是在每個使用者在簽入時，它不會立即就寫入到 Repository。要等到建置完成後才會真正簽入。
( 可以想像成 它跟 SQL 語法的 Transaction 有 Commit , RollBack)
什麼時候可以用它？
版控目錄的規劃可以參考下圖，並分類成 Dev、Main、Production ( 最少要 2 個 )
Dev 是一般開發人員的工作目錄，簽入次數非常頻繁。我們也允許 Change Set 是無法正常編譯
Main 就代表程式都要經過測試過、整合過才能合併進來，而且也只有特別有權限的人員才能存取
基於這樣子的規劃，會比較建議 Dev 用 「持續整合」，Main 可以用 「閘道簽入」
知道使用時機後，接下來我們看一下 整個的運作機制吧！
設定非常簡單，只要在觸發程序中改成「閘道簽入」就可以了！
----------------- 回到 開發人員 --------------------------------
接下來我只要把程式碼做 「簽入」或是「合併」
因為有設定簽入原則，可以看到單元測試有通過基本的要求。( 這個部分若沒有設定的話就會跳過 )
測試都通後， TFS 2010 會提醒這次的 Change Set 會先放在 擱置集
------------------- 回到 Build Server ----------------------------------------
簽入後馬上就觸發 Build 的動作
詳細的資訊
可以看到編譯成功，但有 8 個測試沒有通過，所以建置結果是失敗的
------------------ 回到開發人員 ----------------------------------------------
系統會主動通知剛剛簽入的無法正常通過建置
這個時候可以由本人 或是 指派其他人員 來協助修改「擱置中的程式碼」
按下去解除擱置後可以看到剛剛由 Build Server 產生的「擱置集」
那麼剛剛簽入的檔案怎麼了？
回到 版本管控的介面可以看到，剛剛要簽入的檔案還是保持在「簽出」的狀態
所以可以看到，閘道簽入可以讓管理人員避免沒有經過驗證、測試就把程式碼放到 Main 的分支中
這個部分對於跨不同分支管理時非常有幫助