TFS 中用于报告服务项目的最佳文件夹结构是什么
我正在寻求一些帮助来确定 TFS 中报告服务项目的有用文件夹结构策略。有人对我应该采用哪种方式构建 TFS 有一些建议吗？它应该是每个报告一个项目，还是应该是一个报告项目，在主目录下有多个文件夹，其中包含所有报告项目？
IE Senario 1（每个报告项目都有单独的项目）
$ReportProject1
$ReportProject2
$ReportProject3
Senario 2（TFS 中的主报告项目以及包含报告项目的子文件夹）
$ReportingServices
------来源
---------项目1
-----------ReportProject1 文件
---------项目2
-----------ReportProject2 文件
---------项目3
-----------ReportProject3 文件
I'm looking for some help on deciding a useful folder stucture strategy for reporting service projects in TFS. Does any one have some suggestions on which way I should stucture TFS? Should it be a project per report or should it be one Reporting project with multiple folders under the main that contain all the report projects?
i.e.
Senario 1 (separate projects for each report project)
$ReportProject1
$ReportProject2
$ReportProject3
Senario 2 (Main report project in TFS and subfolders with report projects)
$ReportingServices
------Src
---------Project1
-----------ReportProject1 files
---------Project2
-----------ReportProject2 files
---------Project3
-----------ReportProject3 files
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我倾向于团队项目越少越好。这些报告是否属于逻辑“包”？您是否绝对需要单独管理它们？您是否足够灵活，能够在多个项目中处理单个项目？
在确定团队项目范围时，无论其中存储的解决方案类型如何，我都会尝试在粒度和可部署性之间找到最佳平衡。请记住，如果您要设置工作项跟踪、团队构建或要使用项目门户 - 每个团队项目实际上都会成为它们之间的描述。
对于像 WIT 这样的东西，您可以通过功能区域来提供分离。如果您打算保持简单明了，那么基本上每个项目都会有一个构建。对我来说，在最终决定中，门户通常不是一个卖点，尽管有时我映射到团队项目的 AD 安全组使这一点变得更加重要。
在不了解你具体情况的情况下，我还是倾向于你的“情景2”。必须在团队项目之间切换并知道哪个是哪个，这比我想要持续进行的操作要多敲几次键/单击。如果我想对几个报告进行分支，我也可以分支比需要的更多的分支，而不是维护多个分支。
I would lean towards the fewer Team Projects, the better. Do the reports fall into logical "packages"? Do you have an absolute need to manage them separately? Are you flexible enough to work with a single project over multiple projects?
When scoping Team Projects - regardless of the type of solutions stored within them - I try to come up with the best balance between granularity and deployability. Remember, if you are going to set up Work Item Tracking, Team Builds, or are going to use Project Portals - each Team Project effectively becomes a delineation between them.
For things like WIT, you can provide separation through Functional Areas. Builds, you are going to basically have one per project if you plan on keeping it simple and straightforward. Portals are usually not a selling point one way or the other in the final determination for me, although sometimes the AD Security Groups that I map to the Team Projects makes this a little more important.
Without knowing the details of your situation, I would still lean towards your "Scenario 2". Having to switch between Team Projects and know which one is which is a few keystrokes/clicks more than I would want to have to do on an ongoing basis. If I wanted to branch a couple of reports, I would just as well branch more than needed than maintain multiple branches.