What is the optimal VSTF source structure? Are there any best practices?

Question

There are a number of other questions related to this topic:

1. Whats a good standard code layout for a php application
2. How to structure a java application, in other words: where do I put my classes?
3. Recommended Source Control Directory Structure?
4. Structure of Projects in Version Control

I could not find any specific to VSTF, which has some capabilities like Team Build, integrated Unit Testing, etc... I'm wondering if these capabilities lead to a slightly different source layout recommendation.

Please post example of high level directory structures that you have had good luck with an explain why you like them. I'll let people vote on a "best" approach and I'll award the answer in a few days.

Answer 1

Here is one that I like:

• Private; all of the current system deliverables
  • Documentation; a rollup of all the documentation across the solutions that make up the product, output would be MSDN style documentation from Sandcastle
  • Common; Visual Studio SLN that contains all the projects that are common across all the other solutions.
  • Tools; Visual Studio SLN that contains all the projects whose output is a tool. Example might be a console app that performs a set of administrative task on the larger system
  • Developer; each developer has their own folder which they can use for storing whatever they want
    • Specific Developer (1..n); this contains any build settings, scripts, and tools that this specific developer chooses to store in the source control system (they can do whatever they want here)
  • Specific Deliverable Solution (1..n); Visual Studio SLN that contains all the projects for a specific major deliverable
    • Common; solution folder that contains Visual Studio Projects that are shared within the current solution
    • UI; solution folder that contains Visual Studio Projects that define user experience
    • DataLayer; solution folder that contains Visual Studio Projects that define a data access layer
    • Services; solution folder that contains Visual Studio Projects that define web services
    • Tools; solution folder that contains Visual Studio Projects that define tools specific to this deliverable (executable utilities)
    • Tests; solution folder that contains Visual Studio Projects that contain unit tests
• Public; all of the external dependencies associated with the system (eg. 3rd party libraries)
  • Vendor; dependencies provided by a specific vendor
• Build; Visual Studio SLN that contains code associated with the build of the project, in our case mostly custom MSBuild tasks and Powershell scripts
• Target; each successful build of the product as well as point releases
  • Debug; all of the debug builds that are output from weekly builds and continuous integration. Developers do not manually manage this directory
    • Build Number; a directory that corresponds with the current build number
      • Solution Output; a directory that contains all the build output for each of the projects in a given solution
  • Release; all of the release builds that are output manually when a milestone is reached
    • Build Number; a directory that corresponds with the current build number
      • Solution Output; a directory that contains all the build output for each of the projects in a given solution

Note: All solutions will have a Tests folder and unit test projects.

Answer 2

A few thoughts:

• Very few files in the root of the tree. On a large team, set permissions so that no one can add new files to the root of the tree, without some kind of authorization.

The default workspace will contain:

• Tools contains all executable code required to build & run unit tests, including your custom tools and scripts (perhaps assuming that Visual Studio and PowerShell are already installed on the machine).

• ReferencedAssemblies has things you pick up from somewhere else, including things you buy or download and things someone on the team wrote but isn't part of this project.

  • If available, source code should be in here, too, so you can service it yourself. (If not available, you're taking a big riks.)

• Source - all the source code, including project files.

• Documents - items that are not used as part of the build, but are necessary for the proper functioning of the development effort.

• Binaries - bits that have been shipped to customers, including .PDBs and other artifacts necessary for servicing. (On small projects, I fork the sources for each release, but normally a tag/label is a better choice.)

---

Elsewhere (e.g. $/personal) have a place for each person to do with as they please ($/personal/USERNAME). For example, my side projects go here.