Geeks With Blogs
Snowflake Design Because in Architecture the Answer is Usually "It Depends"

The below repository structure is taken from a couple of sources and personal experience.  Part of it is from the TFS Guide. Now don't dismiss it just because it comes from the TFS guide. It has great advice which applies to other source code repositories not just TFS. I am actually not a fan of TFS, prefering either Subversion or Git. Some of the structure also comes from Visual Studio Team System: Better Software Development for Agile Teams.

<Root>
    /Development
        /FeatureBranchXName
            /<Branched From Main>
        /FeatureBranchYName
            /<Branched From Main>
    /Main
        /Builds
            /Certificates
            /Scripts (Contains build scripts)
            /Tools (A dir for each tool)
                /XMLPreprocess
                /etc.
        /Docs (Contains product docs etc Shipped to customer)
        /Source solution (.sln files)
            /Code (Contain folder for all source)
                /ClassLibrary1 (Contains ClassLibrary1.csproj)
                /MyApp1Web (Contains MyApp1Web.csproj)
            /Database (Depending on whether or not db is shared with other applications you may not want this here)
            /UnitTests (Container folder for unit tests)
                /ClassLibrary1.UnitTests (Contains test project and code)
                /MyApp1Web.UnitTests (Contains test project and code)
            /SharedBinaries (Shared binaries e.g. libraries)
            /SharedSource (Shared source code)
                SolutionInfo.cs (Shared file used to contain assembly attributes like copyright, NeutralResourcesLanguageAttribute, etc)
        /Tests (Container for tests Testcases - Only needed if not using a tool like Quality Center)
            /FunctionalTests
            /PerformanceTests
            /SecurityTests
    /Maintenance
        /Release1
            /<Branched From Main>
        /Release2
            /<Branched From Main>
    /Safekeeping
        /Release1
            /<Branched From Main>
        /Release2
            /<Branched From Main>
    /Spikes
        /...
    /Tags
        /v1_0_0_0
 

Most of the folders are self explanatory, but let me give a quick synopsis but you can get details from the TFS Guide.

  • Root

Now the location of this will depend on what repository you use, for example for Subversion, I typically use one repo per system.

  • Development

Typically used for team/features branches which you may or may not use depending on your branching strategy. I'll be covering that in an upcoming post.

  • Main

As the name implies, this is synonymous to Trunk but I used Main to keep Subversion terminology from leaking into the structure

  • Builds

Root folder for all things related to the build process.

  • Certificates

Contains thinks like your snk file or authenticode cert

  • Scripts

Hopefully self-explanatory

  • Tools

Parent folder used to contain subfolders for each of the tools used during the build process.

  • Docs

Folder for documentation that will be shipped to the client (i.e. help file project files)

  • Maintenance

Folder containing branches which are currently under active maintenance (i.e. code in production)

  • Safekeeping

Folder containing archived branches.

  • Spikes

Folder containing spike projects for the system that root is for. This lets people have version control for spikes and gives and can even give you glimpse as to why certain approches were taken on production code if a spike was used to test out theories.

  • Tags

Typically only used if your repository needs a physical folder to contain tags (i.e. labels)

Here's a picture that I think is a little easier to see than the above ASCII tree.

Some additional things to note. Underneath the code folder I typically name the folder containing the project to match the project name which in turn matches the name of the assembly (The root namespace of the project also matches the assembly name). The unit test project for that project uses the same name as the project the unit tests will be covering but the the ".UnitTests" suffix. This is because you may also have an integration tests assembly. I typically use different projects for unit and integration tests to make it easier to separate when the tests will be run by the build environment.

I've been on the fence about using SharedSource vs. just having the files right in the Source folder (at the same level that the .sln files are put). Still not sure but I've shown the SharedSource folder in this post so that you can make up your own mind.

I like having the tools included (and anything else you need to build) in source control so that when you checkout the project, you have everything you need to build. I don't like having the tools (or other dependencies) in a separate location in the repository and then having to checkout both the project and the tools and needing to put the tools in a well known folder so that your project can reference them...

I'm also a big fan of XMLPreprocess, and the MSBuild Extension Pack projects.

In the upcoming posts I'll talk about how to increment version numbers, get the build going, etc.

Posted on Friday, December 18, 2009 10:15 PM | Back to top

Copyright © Carlos Santos | Powered by: GeeksWithBlogs.net