如何跟蹤部署的文件

Question

我們正在尋找更好的替代方案，以目前我們部署的方式。我正在尋找任何建議。請注意我們使用的當前系統是我曾經使用過的唯一系統。我們很不高興，因爲它很容易出錯（你會在細節中看到我的意思）。另外請注意，我們正在從SourceSafe遷移到TFS。

我們的公司：
我工作的養老金制度。我們的大部分代碼都在內部使用，儘管它們在我們的外部網站上使用了部分代碼

架構：
我們大部分的代碼是基於2層。我們的數據庫方案非常大......我們有6000個存儲過程和1000個表。開發人員同時開發.net代碼&存儲過程。

如何我們目前部署工作：
SourceSafe中，我們有3個文件夾$ /開發，$ /測試，$ /生產對應於開發/測試/生產數據庫。

我們有一個本土問題跟蹤應用程序。我們將處理$/Dev分支中的所有問題。然後，我們將創建一個文件，其中包含我們隨文件的sourcesafe版本＃一起更改的每個文件（存儲過程/ .sql文件與其他所有文件一樣放在sourcesafe中）。這些將會給予將所有文件從$/dev移動到$/test文件夾的部署人員。其他部署人員然後將構建我們所有的應用程序，並針對測試數據庫執行所有存儲過程更改。該問題將由我們的用戶社區的指定測試人員進行測試，並且一旦簽名，文件將從$/dev - > $/prod移動。部署團隊擁有一個電子表格，以確保沒有文件永遠不會使其到達$/Prod，除非它被註銷。

問題，我們面臨：
首先應該明白如何容易出錯，這是。錯過的文件或不正確的版本文件數量對於大型項目尤爲常見。

我想要任何建議，或者如果有人有一些良好的閱讀部署策略。正如你所看到的，我們與傳統的公司有很大不同，我們已經閱讀了大部分內容，這些傳統公司都有發佈構建類型的結構。

Answer 1

我建議在TFS中有3個分支：DEV/TEST/PROD。

而不是讓文檔來跟蹤DEV中的所有更改，只需讓TFS爲您執行此操作即可。當您準備好推廣您對TEST的更改時，只需從DEV - > TEST進行合併（這稱爲TFS術語中的反向集成）。

如果您希望能夠在DEV中同時處理多個「問題」，並且只提升與某個問題相關的更改，則可以使用作爲DEV分支的子項存在的功能分支。只有當問題完成後，它纔會移到DEV分支。如果您使用這種分支策略，您可能不需要單獨的TEST分支，因爲您的測試人員可以簡單地使用僅包含已完成問題的DEV操作。

對於部署，建議取決於您需要部署的內容。由於您只提到數據庫，因此我將重點介紹可用於此的工具。您可以在Visual Studio中創建一個數據庫項目，它可以在某個時間點表示數據庫模式和數據。這是源控制就像任何其他VS項目。當部署團隊希望部署它時，他們會使用Visual Studio或命令行工具（對於操作類型的工作人員來說更常見）。該工具查看VS中的數據庫項目，並將其與實時數據庫進行比較，並生成一個sql腳本，您可以對實時數據庫執行該腳本以使其與VS項目匹配。整個過程可以很容易實現自動化（最好在TFS構建中）。

我的目標是讓TFS構建定義觸發了隨時將代碼簽入TEST（或使用功能分支的DEV）。這會自動構建所有代碼，並將任何數據庫和其他工件部署到相應的測試環境。