我在一個認爲將代碼直接從Team Foundation Server（TFS）直接部署到生產環境中的好主意的地方工作。說服他們這是一個糟糕的主意幾乎是不可能的，因爲他們只能責怪程序員檢查他的代碼。部署.NET Web應用程序的最佳實踐
TFS並不總是透明的。你可能知道。並且可能會無意中檢查您的更改。
我想賣給他們比這更好的東西，除了我不知道它是什麼。我不能使用正確的Google關鍵字，因爲當頁面或鏈接談論部署時，它不會將部署作爲軟件週期的一部分來討論。 IE，「.NET部署的最佳實踐」將討論從您的項目發佈，IIS設置等。
有一個更好的方法。代碼凍結？代碼分支？是不是有一種方法可以一次部署應用程序而不是整個Web應用程序？
你看過TFS部署者嗎？我已經在我們的客戶之一使用它，並且它出色地工作。它的工作原理是捕捉和行動TFS提出的關於TFS中構建質量變化的事件。一旦捕獲到事件，TFS部署者服務將爲您提供放置位置的路徑以及更改構建質量的用戶。用戶身份使您有機會圍繞它建立您的安全和權限矩陣，如果您想抓取部署者並部署構建，則放置位置非常方便。如果完全支持電源外殼，cmd和wix。看看這個博客文章=>http://geekswithblogs.net/TarunArora/archive/2011/05/21/tfs-deployerndash-automate-deployments.aspx我正在部署Web和TFS部署者的數據庫，完全自動化並記錄下來。讓我知道如果我能提供任何進一步的細節
HTH 乾杯，塔倫已採取
塔倫，謝謝你的努力，但不，這並沒有幫助。我真的需要一個官方最佳實踐文檔的大棒，上面寫着：「沒有！壞經理！不！不從TFS直接生產」TFS部署者對於一個小公司來說是好事，跪在微軟的祭壇上。這是一家大公司。我保證你已經聽說過我們，很多人使用我們來收看有線電視;）公司絕不會接受第三方構建經理，即使它真的非常好用（codeplex網站上的'討論'選項卡，例如，將不得不從他們隱藏） –
啊，我看到，TFS部署可能是一個快速的勝利。但我想在你的情況下，你可能不得不進入精細的實驗室管理，Msbuild自定義任務，等等等等...... http://channel9.msdn.com/Series/ALM-Summit-2010/Making-Continuous-交貨-A-現實 –
部署（IMO）數據庫/網站的
從技術上講沒有什麼錯，直接從TFS釋放到生產，只要你」一路上已經充分測試了代碼。
其中不少具有開發夢想變爲類似的代碼
當然，沒有太多的開發公司有足夠的單元/自動化測試，他們覺得安全地推動它快速生活。
TFS部署者在後臺做了很多工作，大多數人甚至不會知道它不是TFS的功能。它還可以與所有構建和測試功能大量集成，從而確保代碼質量首先處於良好狀態。
代碼凍結是一個壞主意，你不希望你的開發資源在不允許觸摸代碼的地方停機。相反，你應該看看適合你的分支策略。有很多在那裏，但這裏的主3我能想到的：
質量爲基礎的 - 你保持一個分支的開發，一個用於分期，一個用於生產。當代碼通過每一組測試時，您都將其變更集手動合併到下一個分支中。這也意味着您可以輕鬆修復生產中的錯誤，而無需發佈尚未準備好的新更改
基於版本 - 您在主分支中進行所有開發，當版本完成時，您將其分支並僅觸摸分支來修復錯誤。這也允許您在不發佈新的未經測試的代碼的情況下針對實時（或您可能支持的任何其他版本）進行錯誤修復。
基於功能 - 所有開發都發生在新分支中，一旦完成，它將合併回主幹。樹幹是唯一被釋放的分支。
我會建議不分支，直到需要分支。很多人不知道你可以從一個特定的變更集/日期分支出來。這意味着如果你知道什麼時候發佈了，你可以在需要應用錯誤修復時將其分支，然後將它合併回主幹。當然，由於您需要始終知道服務器上運行的是什麼變更集，因此需要更多的關於釋放的規定。
當然，我可能會錯誤地閱讀你的文章，也許你並沒有要求有關部署的最佳實踐，而是真正問如何讓你的經理相信事情在他們上線之前需要進行測試。如果是這樣，你有更大的問題。開發人員（通常）不是很好的測試人員，當然不是他們編碼的東西。如果您沒有專門的測試人員和流程來執行單元測試和自動化測試，那麼您應該首先考慮這一點。
您是使用Visual SourceSafe（VSS）還是使用Team Foundation Server（TFS）？ –
VSS，BTW，大約還有360天的支持。請參閱http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&qid=&alpha=Visual+SourceSafe+2005&Filter=FilterNO –
我們使用的是TFS。對不起，我以爲我說得很清楚。 –