TFS Folder Structure

An article by Tevyn No Comments

I’m looking at setting up a TFS folder structure at work and I’m not convinced that Microsoft's standards for this won’t satisfy me.  Below are two different suggestions, please feel free to comment or provide your own experiences. Feedback is wanted. The project has a front end web site using MVC 3, a web service WCF & Entity, and a backend SQL Server.

--------

Suggestion 1

Based from Microsoft’s suggested structure (http://msdn.microsoft.com/en-us/library/bb668954.aspx).

/ProjectName

• Main
  • Source
    • App1 (ASP.Net MVC 3)
      • Source (Holds the solution and it’s containing projects).
      • Unit Tests
    • App2 (WCF & Entity)
      • Source
        • Project(s)
        • UnitTests (or Unit tests underneath the source solutions)
    • Database (This isn’t covered by MS. More notes below.)
  • Tests
    • Functional
    • Security
    • Performance
• Development (the name confuses me, because I think it is the main working trunk. Branches is better).
  • Branch1
    • Source
• Releases
  • Release1
    • Source
      • App1

Suggestion 2

Below is a methodology that I have used in the past. I like it because of the separation of release for the individual tiers (Web site, Web service, Database).

/ProjectName

• App1 (ASP.Net MVC 3)
  • Trunk/Source/Main (Main : contains the entire solution including the unit test projects)
  • Branches
    • BranchName1 (copy of the trunk)
    • BranchName2
  • Releases (Tags)
    • ReleaseVersion1.1 (copy of trunk at release)
• App2 (WCF & Entity)
  • Trunk/Source/Main
  • Branches
  • Releases
• Database (This is a new concept for me: reference http://www.codinghorror.com/blog/2008/02/get-your-database-under-version-control.html)
  • Trunk (More notes below).
  • Branches (branched database changes)
  • Releases
    • ReleaseVersion1.1 (copy of creation script)

--------------------------

Multiple Solutions:

Depending on if there is separation of duty helps to determine if the Web site and the web service should be in separate solutions. If we are all working both projects it may be convenient for it to all be within the same solution. I like the idea of separate solutions, because the best practices is to keep the UI and the Web Service independent of each other. If we ever need to make a “Silverlight” project we would not have to copy the web service and start a new trunk/release for it.

Unit Testing:

What is under Suggestion 1 - App1/App2 is subject to debate. I think that it would be convenient to have our unit test projects within the same solution. However, the other side of the argument is that you don’t need “Unit Tests” copied to your Releases, so having the source separated would be ideal. Microsoft also suggests helpful pros and cons, but my preference is UnitTests in each project based on the advantages for a developer.

UnitTests as a Peer to the Source folder

• Pro: You can find unit tests in one place.
• Pro: You separate shipping code from non-shipping code.
• Pro: Your build process can easily run all unit tests across all projects.
• Con: It is harder for developers to run unit tests for their project only.
• Con: When you branch source, it will not include unit tests.

UnitTests in Each Project

• Pro: Developers can easily run unit tests on a single project.
• Pro: When you branch, your branched folders include unit tests, so they can stay tightly bound to the source in each branch.
• Con: You mix shipping with non-shipping code in the source folder.
• Con: It is generally harder to run all unit tests at once at build time across all projects.

The above pros and cons are from Microsoft’s Chapter 4 – Structuring Projects and Solutions in Team Foundation Source Control.

Database:

The database could be a copy of the create schema, a modal backup file, or we could separate it (tables, views, stored procedures). We also need to consider “Upgrade” scripts when we design this. Another suggestion is to have the code/backups located inside the source code next to the application, consider placing it with the dependent WCF project source code. I have no experience with TFS and its capabilities to version control a database, there may be a feature that will provide this functionality without use designing and backing up .sql files. Research needed.

--------------------------

What do you think?