Guidance: How to layout you files for an Ideal Solution



vs2010almCreating a solution and having it maintainable over time is an art and not a science. I like being pedantic and having a place for everything, no matter how small.

For setting up the Areas to run Multiple projects under one solution see my post on  When should I use Areas in TFS instead of Team Projects and for an explanation of branching see Guidance: A Branching strategy for Scrum Teams.


Whenever I setup a new Team Project I implement the basic version control structure. I put “readme.txt” files in the folder structure explaining the different levels, and a solution file called “[Client].[Product].sln” located at “$/[Client]/[Product]/DEV/Main” within version control.

Developers should add any projects you need to create to that solution in the format “[Client].[Product].[ProductArea].[Assembly]” and they will automatically be picked up and built automatically when you setup Automated Builds using Team Foundation Build.

All test projects need to be done using MSTest to get proper IDE and Team Foundation Build integration out-of-the-box and be named for the assembly that it is testing with a naming convention of “[Client].[Product].[ProductArea].[Assembly].Tests”

Here is a description of the folder layout; this content should be replicated in readme files under version control in the relevant locations so that even developers new to the project can see how to do it.

Figure: The Team Project level – at this level there should be a folder for each the products that you are building if you are using Areas correctly in TFS 2010.

You should try very hard to avoided spaces as these things always end up in a URL eventually e.g. “Code Auditor” should be “CodeAuditor”.

Figure: Product Level – At this level there should be only 3 folders (DEV, RELESE and SAFE) all of which should be in capitals.

These folders represent the three stages of your application production line. Each of them may contain multiple branches but this format leaves all of your branches at the same level.

Figure: The DEV folder is where all of the Development branches reside.

The DEV folder will contain the “Main” branch and all feature branches is they are being used. The DEV designation specifies that all code in every branch under this folder has not been released or made ready for release. And feature branches MUST merge (Forward Integrate) from Main and stabilise prior to merging (Reverse Integration) back down into Main and being decommissioned.

Figure: In the Feature branching scenario only merges are allowed onto Main, no development can be done there.

Once we have a mature product it is important that new features being developed in parallel are kept separate. This would most likely be used if we had more than one Scrum team working on a single product.

Figure: when we are ready to do a release of our software we will create a release branch that is then stabilised prior to deployment.

This protects the serviceability of of our released code allowing developers to fix bugs and re-release an existing version.

Figure: All bugs found on a release are fixed on the release. 

All bugs found in a release are fixed on the release and a new deployment is created. After the deployment is created the bug fixes are then merged (Reverse Integration) into the Main branch. We do this so that we separate out our development from our production ready code. 

Figure: SAFE or RTM is a read only record of what you actually released. Labels are not immutable so are useless in this circumstance. 

When we have completed stabilisation of the release branch and we are ready to deploy to production we create a read-only copy of the code for reference. In some cases this could be a regulatory concern, but in most cases it protects the company building the product from legal entanglements based on what you did or did not release.


Figure: This allows us to reference any particular version of our application that was ever shipped.


In addition I am an advocate of having a single solution with all the Project folders directly under the “Trunk”/”Main” folder and using the full name for the project folders..


Figure: The ideal solution

If you must have multiple solutions, because you need to use more than one version of Visual Studio, name the solutions “[Client].[Product][VSVersion].sln” and have it reside in the same folder as the other solution.

This makes it easier for Automated build and improves the discoverability of your code and its dependencies.

Send me your feedback!


Upcoming Training Opportunities

These are the next five classes we have, and you can check out our full public schedule of classes.

Live Virtual PAL Evidence-Based Management Online on 19th June 2023
19-20 Jun, 2023
09:00-13:00 BST
2 half-days
APS 19th June 2023
19-22 Jun, 2023
09:00-13:00 EDT
4 half-days
Professional Scrum Product Owner Immersion (PSPO-I) online 3rd July 2023 over 8 weeks
3 Jul-21 Jul, 2023
13:00-17:00 BST
8 weekly half-days
PSPO-A 10th July 2023
10-13 Jul, 2023
09:00-13:00 BST
4 half-days

We can deliver any of our courses as private in-house training over Microsoft Teams & Mural. We also recommend training based on your accountabilities or role, you can go directly to recommended courses for Scrum MastersProduct OwnersDevelopers and Agile Leaders.

Create a conversation around this article

Share on Facebook
Share on Twitter
Share on Linkdin

Related Courses

No items found

Read more

Martin Hinshelwood Why do you encourage people to follow a certification path in their career journey? I would encourage you to follow a scrum certification path for the same reason that people go to university. The same reason that people do any course or certification. It gets you a foot in …
Martin Hinshelwood What will you learn on the PSM II course? There are two main things that most scrum masters will learn on the PSM II or Advanced Professional Scrum Master course. That they haven’t been working effectively as a scrum master to date. That they are there to empower and …
Martin Hinshelwood
In Scrum Events across the world, I hear repeated the phrase “that’s how agile works” when describing behaviours that are both unprofessional and the very opposite of an agile mindset. These behaviours will inhibit agility and are a result of a lack of understanding of the underlying principles. We need …
Martin Hinshelwood What is the most common Aha moment people have in a scrum course? It depends on the scrum course they are attending. The content presented in the Applying Professional Scrum (APS) course leads to very different epiphanies when compared to the content presented on an Advanced Professional Scrum Master …


We believe that every company deserves high quality software delivered on a regular cadence that meets its customers needs. Our goal is to help you reduce your cycle time, improve your time to market, and minimise any organisational friction in achieving your goals.

naked Agility Limited is a professional company that offers training, coaching, mentoring, and facilitation to help people and teams evolve, integrate, and continuously improve.

We recognise the positive impact that a happy AND motivated workforce, that has purpose, has on client experience. We help change mindsets towards a people-first culture where everyone encourages others to learn and grow. The resulting divergent thinking leads to many different ideas and opportunities for the success of the organisation.