TFS簽入策略的最佳實踐/你的經歷

Question

我們要使用TFS 2010的一個新項目，我正在尋找有關作爲一個團隊開發時使用的策略檢查中選擇一個最佳實踐和知識/經驗。 我發現了所有這些信息，但沒有提供關於最佳實踐的大量信息，以及開發團隊對政策的意見和經驗，他們使用過或可能應該使用這些政策。你用

• 哪些政策？
• 你有什麼經驗？
• 你會推薦什麼？

例如，您是否使用了微軟最低推薦規則，您是否全部使用它們？

信息和您的經驗表示讚賞。

Answer 1

最重要的簽入策略是：

• 評論政策 - 要求對所有簽到意見。
• 工作項目關聯 - 這應該是強制性的，因爲沒有它你不能將更改集合分組到特定的工作流。你需要能夠做到這一點，以合併和批量回滾更改。
• 封閉式入住 - 儘管不是政策本身（你需要創建一個門版本）它可以防止開發商在打破編譯代碼檢查。如果您在代碼庫中創建了鏈接版本，則可以確保您的解決方案永遠不會因重新登錄而中斷。我已經做到了，它的工作原理。

還有很多其他的（我們使用雙子座項目協會政策），你可以寫你自己的。這並不難，你可以量身定製它們。

Answer 2

嘗試每個簽入的政策，看看他們是否給你的團隊提供價值。

我們的一些團隊項目只需要在評論檢查。有些需要評論和工作項目。有些需要成功構建。這完全取決於團隊的需求。

不要試圖遵循別人的最佳做法。確定什麼在你的環境中起作用。

Answer 3

這更是一個討論的問題，這是不平常的StackOverflow問題想要的類型，但我會咬。

，對我有意義的政策是：

• 構建政策
  • 此策略將阻止失敗構建隊列建立有人打破了構建之後。實際上，您會被警告該構建目前被破壞，以便有人可以在繼續之前修復構建。
• 工作項目協會
  • 我們需要工作項關聯性，以確保我們可以追蹤正在做的通過對測試用例籤工作。
• 工作項查詢
  • 我們希望人們選擇從目前的衝刺/迭代他們的工作。因此，驗證工作人員實際上是否覈准工作是很方便的。
• Custom Path Policy
  • 我們在那個房子裏不止一個項目，我們想要提高質量或安全上的一個項目，但都沒有興趣打擾其他項目組項目，而使用此政策一旦。或者阻止當前版本分支上的某些簽名，但不希望在仍舊保留的舊版本上使用這樣嚴格的策略。

我們通過失敗的CI構建，而不是驗證的幾件事情，你可以通過簽入的政策辦。這主要是爲了節省開發者機器上的時間。

• 代碼分析策略。
  • 我們不使用簽入策略，而是使用CI構建，如果某些代碼分析規則被破壞，將會失敗。這使我們可以讓開發人員在每個構建版本上構建跳過代碼分析。人們會很快學會如何防止這些規則觸發。

我們不使用任何其他政策。對變更集策略的需求評論是我們有時使用的，但大多數團隊在一段時間後實際上不需要針對此策略。沒有對簽入評論被大多數人所詬病，這就解決了。

我們有幾個項目進行時間跟蹤（針對MSF CMMI），我們使用了custom policy to ensure people updated their hours on every checkin。

我們沒有使用任何策略來執行代碼覆蓋率或警告數量。如果需要，可以通過構建過程定製將這些添加到構建中。

我們在需要額外驗證的分支機構上使用門控檢入。如後續自動部署的發佈分支和分支。

我們經常允許開發人員繞過任何簽入政策而不受處罰。門控Checkins也一樣。明智地使用這些權利取決於開發者。打破部署是你在被團隊注意之前不能經常做的事情;）。

這裏也有一些有趣的定製政策，但我知道只有少數人竟然會使用這些。

• Merge only policy
  • 此策略允許您指定幾個分支只能接收工作已經檢查了另一個分支的合併。
• Forbidden Patterns Policy
  • 我有時使用這些以確保沒有/bin/debug，.exe或.dll被檢查到TFS一個//src/文件夾。

有來自第三方几個政策，但我從未使用過這些。這些包括：

• The Checkin Policy Pack並且該頁面列出了一些我從來沒有使用過的額外策略。

不使用太多第三方策略的原因之一是所有團隊成員都需要在他們的機器上安裝polcies。 Team Foundation Server Power Tools可以幫助您解決發佈問題，但這些默認情況下並未在所有開發人員工作站上部署和配置。

另外available in blog form。