什麼是最佳的VSTF源結構？有沒有最佳做法？

有許多與此主題相關的其他問題：什麼是最佳的VSTF源結構？有沒有最佳做法？

我找不到任何具體到VSTF，它具有Team Build，Integr等一些功能單元測試等。我想知道這些功能是否會導致稍微不同的源佈局建議。

請發佈高級目錄結構的例子，你有幸運的解釋你爲什麼喜歡它們。我會讓人們對「最佳」方法進行投票，我會在幾天內給出答案。

來源

2008-09-19 Eric Schoonover

這是一個我喜歡的：

私人;所有當前系統可交付成果
- 文檔;組成該產品的所有文檔的彙總，輸出將是Sandcastle的MSDN樣式文檔
- 常見的; Visual Studio SLN包含所有其他解決方案中通用的所有項目。
- 工具;包含所有輸出爲工具的項目的Visual Studio SLN。示例可以是在較大系統上執行一組管理任務的控制檯應用程序
- 開發人員;每個開發者都有自己的文件夾，他們可用於存儲任何他們想要的
  - 具體開發（1..1）;這包含任何構建設置，腳本和工具，這種特定的開發者選擇在源控制系統來存儲（他們可以做任何他們想要在這裏）
- 具體交付解決方案（1 ..n）;包含特定主要交付物的所有項目的Visual Studio SLN
  - 常見;解決方案文件夾包含在當前解決方案中共享的Visual Studio項目
  - UI;解決方案文件夾，其中包含定義用戶體驗的Visual Studio項目
  - DataLayer;解決方案文件夾，其中包含定義數據訪問層的Visual Studio項目
  - 服務;解決方案文件夾，其中包含定義Web服務的Visual Studio項目
  - 工具;包含Visual Studio項目的解決方案文件夾，該文件夾定義特定於此可交付項目的工具（可執行實用程序）
  - 測試;包含含有單元測試
公共 Visual Studio項目解決方案文件夾;與系統相關的所有外部依賴（例如第三方庫）
- 供應商;依賴關係由特定供應商提供
構建;包含與項目構建相關的代碼的Visual Studio SLN，在我們的案例中主要是自定義MSBuild任務和Powershell腳本
目標;產品的每個成功構建以及點發布
- 調試;從每週構建和持續集成中輸出的所有調試版本。開發人員不會手動管理此目錄
  - 內部編號;與當前版本號對應的目錄
    - 解決方案輸出;包含在一個給定的解決方案
- 發行每個項目的所有構建輸出目錄;當達到里程碑時手動輸出的所有發佈版本
  - 內部版本號;與當前版本號對應的目錄
    - 解決方案輸出;包含所有對每個項目的生成輸出在給定的解決方案

注目錄：所有的解決方案將有一個測試文件夾和單元測試項目。

來源

2008-09-19 01:00:35

的一點想法：

根樹的很少文件。在大型團隊中，設置權限，以便沒有人可以在沒有某種授權的情況下將新文件添加到樹的根目錄。

默認工作區將包含：

工具包含構建&運行單元測試，包括您的自定義工具和腳本（也許假定的Visual Studio和PowerShell已經要求所有可執行代碼安裝在機器上）。
ReferencedAssemblies擁有的東西，你從別的地方，包括你買東西或下載的東西有人在隊伍中寫道，但不是該項目的一部分回暖。
- 如果可用，源代碼也應該在這裏，以便您可以自己提供服務。（如果沒有可用的，你正在做一個大RIKS。）
來源 - 所有的源代碼，包括項目文件。
文檔 - 不作爲構建的一部分使用但是開發工作正常運行所必需的項目。
二進制文件 - 已位運給客戶，包括.PDBs和必要的維修等文物。（小型項目，我叉各版本的來源，但通常標記/標籤是一個更好的選擇。）

在其他地方（例如：$ /個人），必須爲每個人做的地方隨心所欲（$/personal/USERNAME）。例如，我的項目就在這裏。

來源

2008-12-29 07:04:18

什麼是最佳的VSTF源結構？有沒有最佳做法？

回答

相關問題