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 $ReportProject3Senario 2 (Main report project in TFS and subfolders with report projects)
$ReportingServices ------Src ---------Project1 -----------ReportProject1 files ---------Project2 -----------ReportProject2 files ---------Proj开发者_如何学Pythonect3 -----------ReportProject3 filesI 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.
精彩评论