我很抱歉這篇文章的長度，但我需要包含大量的信息以獲得正確的答案。我希望這不會阻止迴應...TFS和one-up的發佈
我們的商店歷史上編碼的網站使用經典ASP與一些較新的ASP.NET網站配置爲網站。衆所周知，這意味着源文件（* .asp，* .aspx，和 * .aspx.vb（或* .aspx.cs））文件按原樣部署到開發和生產服務器。
配置管理過程是（現在仍然是）完全手工幷包含有以下步驟：（要求）：
- 以修改過的文件的副本，並在「釋放」的文件夾存儲它們用於存檔。
- 取出將被替換的生產文件的副本並將它們存儲在「存檔」文件夾中以便於回滾。
- 在診斷髮布後問題時，生成源代碼文件之前和之後的代碼審閱或一般參考的差異報告。
- 對變更進行編碼的開發人員不是執行生產版本的人員。原始開發人員需要將源文件文件交給其他開發人員進行一些額外的測試和生產部署。
爲了讓情況更加困難（不是上述情況，而是我在下面討論的內容），我們不遵循正式的發佈計劃。由於個人錯誤或增強功能已完成，因此已發佈。這意味着我們可以很容易地每週向一個網站發佈多個版本。甚至有可能某個網站在同一天獲得兩個不同版本個人頁！
自從我加入這個團隊後，我一直在嘗試將團隊轉移到像ASP.NET Web應用程序和ASP.NET MVC這樣的新技術。 （我們還承擔了用於非web進程的獨立應用程序和控制檯實用程序的責任...所以我的困境仍然適用。）
這些技術與傳統技術的區別在於預編譯。而不是部署代碼隱藏文件（* .aspx.vb（或* .aspx.cs）），部署dll或exe文件。這種類型的部署包提出了幾個問題（問題??）。
- 編譯源代碼時生成差異報告。雖然新修改的源文件位於開發人員系統上，但生產副本是一個編譯副本。
- 確保特定版本中未包含與其他錯誤或增強相關的更改。這將適用於原始開發人員和執行發佈的人員。
- 允許原始開發人員將更改後的文件傳遞給另一位開發人員進行構建，測試和部署。
到現在爲止我是只在球隊上面，其中不存在提到的這些類型的網站和應用程序，使矛盾和問題的工作開發。 （我跳過了差異報告步驟，我做了自己的部署）。但是，我試圖推動團隊的其他成員接受這一點，並允許更好地分發錯誤和增強任務。
我們正在使用VSS，但我正在推動（並且很可能成功）讓我們轉移到TFS。我有一些想法是
設置一個單獨的構建系統供開發人員使用來進行部署。這將解決兩個問題 - （1）開發人員之間的Visual Studio和其他庫的不同版本/補丁程序;（2）執行發佈的人已經在本地檢出文件以進行其他更改的情況。 （當然這並不能保證構建系統和原始開發人員之間的差異，但至少這意味着發佈版本是來自一致的配置。
使用標籤來標記修改過的文件我的問題是，雖然我可以識別修改過的文件（並下載構建）修改後的文件，我如何識別需要包含在內部的文件，但是而不是已被修改。同樣，這個想法不包括檢入與un有關的文件 - 發佈的更改
使用標籤標記發佈的所有文件（修改的文件和未更改的文件）。我的問題與上一個類似...我如何確保文件C由另一位開發人員（假設他們去度假）加入了一個不相關的更改，但未被標記幷包含在此版本中。
使用標籤我可能會寫一個腳本來爲標籤版本和以前標籤的版本生成差異報告。如果該過程正常工作，那麼應該產生確切什麼變化包括在特定的版本..？
任何其他想法，關注點，興趣點？雖然我確實具有某些流程的靈活性，但某些要求（如差異報告或某種方式可輕鬆查看差異並擁有單獨的開發人員/部署人員）很可能不可觸及。
非常感謝您爲此提供的任何幫助。
我們只需要保持兩個開發人員不同時合併發佈的紀律。 （除非我們**希望**同時推送兩個更改。）正確嗎？ – Jason
正確。溝通是關鍵:) –
讓我在閱讀你的鏈接和更多關於分支概念之前，先給我答案。雖然我知道分支（儘管從來沒有使用過），但我沒有想到我的困境。你是否預見標籤仍然扮演着一個角色？也許只是爲了識別變更集（正確的術語？），還是SP與bug和任務的整合覆蓋了這些？我的理解是，我可以配置環境以要求將檢出（或檢入）與指定的錯誤或任務相關聯。 – Jason