什么是最佳的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源结构？有没有最佳做法？

回答

相关问题