How should I structure my VSTS project folders?

Question

I am trying to understand how I should structure my TFS/VSTS Folders and local workspaces/folders/mappings, etc. I am looking for a best practice approach I can follow along.

Currently I have got two projects within my VSTS account:

$/ProjectA
+- Main
  +- ProjectA 
    +- ProjectA
    +- ProjectA.sln 

$/ProjectB
+- Main
  +- ProjectB 
  +- ProjectB.sln 

As suggested by this MSDN link I have created a 'main' folder at the root of the project. So I am able to create branches in case it is needed later.

Please note that ProjectA has an additional folder called ProjectA, which was created by Visual Studio, when using the new project wizard and checked "Add to source control".

Regarding ProjectB: First I have created the solution without adding it to source control. But then later moved the solution into the folder that is locally mapped. And afterwards opened the solution and choose "Add solution to source control".

I have got one workspace, called: "MyWorkspace". The path mappings within this workspace are set as follows:

$/ProjectA ==> C:\Dev\Projects\ProjectA  
$/ProjectB ==> C:\Dev\Projects\ProjectB

NB: Both projects have nothing to do with each other.

Questions:

1. How should I structure my folders within the VSTS project? At which level should the .sln file reside?

2. How should I structure my local folders and the mappings?

3. Should I use one workspace containing all project-mappings or one workspace per project? Or should I even have multiple workspaces per project as suggested by some blogs? (sorry cant find the link anymore)

Answer 1

I agree with Flater, This question is completely subjective.

However MSDN provided the suggestions on using the server-side structure and client-side structure, also Branched Folders and Workspaces explained.

Strategies for Solution and Project Structure

The three most common strategies used to structure solution and project files are:

• Single solution. If you work on a small system, create a single solution and place all of your projects within it.
• Partitioned solution. If you work on a large system, use multiple solutions to group related projects together. Create solutions to
  logically group subsets of projects that a developer would be most
  likely to modify as a set, and then create one master solution to
  contain all of your projects. This approach reduces the amount of
  data that needs to be pulled from source control when you only need
  to work on specific projects.
• Multiple solutions. If you are working on a very large system that requires dozens of projects or more, use multiple solutions to work
  on sub-systems but for dependency mapping and performance reasons do
  not create a master solution that contains all projects.

In general you should:

• Use a single solution strategy unless the resulting solution is too large to load into Visual Studio.
• Use multiple solutions to create specific views on sub-systems of your application.
• Use multiple solutions to reduce the time it takes to load a solution and to reduce build time for developers.

Please refer to below links for details:

• Strategies for Solution and Project Structure
• Structuring Projects and Solutions in Team Foundation Source Control

---

In some cases, you can create multiple workspaces to isolate and switch among the changes you are making in different branches.

If you’re using local workspaces, then you can see some performance benefits by switching to using “one branch == one workspace”. Please refer to phkelley's blog for details:

TFS Version ControlUsing multiple workspaces with Visual Studio

You can also reference jessehouwing's answer on how to use the workspace: https://stackoverflow.com/a/48355207/7466674