Defining a Development Tree

// May 10th, 2008 // Programming

Having a cleanly designed dev tree can be more important than many developers might at first think. Having looked at not only how I do things, but how Huddle structures their dev tree I decided to do some research into designing the perfect dev tree.

Here were my findings:

  • Namespaces should follow folder structure. Much like how Java and packages work. Using Resharper will flag when this rule is broken. e.g. Huddle.Web\Modules\CustomUrl.cs -> Huddle.Web.Modules.CustomUrl.
  • Namespaces should follow <% Company Name %>.<% Project Name %>.<% Sub Project %>, e.g. Huddle.Domain.Entities.
  • Project folder names, and assemblies names should be atomic. e.g. The project Huddle.Web.UnitTests should live in a folder named Huddle.Web.UnitTests and also have an assembly (dll) by the same name. This is a common standard in C# and in Java.
  • All public classes should have their own C# file, and not sit nested within other class files.
  • Source control should not contain temporary, user, or ReSharper files, or any other temporary or generated file.
  • A dev tree should not be path specific. I should be able to checkout, build and run a dev tree in C:\Dev, or C:\Code etc… It shouldn’t be dependent on a being in a certain folder.
  • Shorter root folder names are better and help stop breaking the folder path limit Windows has. e.g Instead of “C:\Development” a better alternative would be “C:\Dev”. The same applies to folders within the dev tree, such as having “lib” instead of “Assemblies”.
  • Tools related to the build should be included in source control. Things such as NAnt, NCover etc… should be within a “tools” folder. This makes updates to environments easier, and ensures all developers have the same version of each application.
  • Developers should be able to run the NAnt build scripts locally. A “dev” version of the build script should be available, running most of the build processes (apart from things like deployment etc…). This provides a better reflection of the build environment for developers and reduces the chance of the build being broken.
  • A batch file (with no logic, just a reference to the NAnt build script) should be in the root of the dev tree, e.g. Go.bat. Developers can use it to run the build and all the metrics (FxCop, NUnit etc…) and see if they’ve broken the build or not. Also, non Visual Studio users can build the application without needing to open Visual Studio.
  • A slightly more controversial point is that all projects should live within the same repository. For example we currently have one repository for the public website, and one for the user application. This really depends on your setup though.

With all the above in mind, I set out designing the dev tree. Being very fond of NetBeans and the way it sets out projects I took a very similar approach.

Here are the basic characteristics of our new setup:

  • Developers work from a second partition. The first partition contains the operating system, and hence should remain separate. This also makes re-ghosting/installing the operating much easier/faster as all your files (which are going to vary between users) are on a separate partition.
  • One rule was that the dev tree should work no matter where it is located. However, still applying this rule, we also decided that all developers should work from an agreed location, for more consistency or if having to work via some else’s pc. We decided on “D:\dev”.
  • All folders should be lowercase apart from project folders (i.e. such as Huddle.Web) and folders within those projects.
  • To stop unwanted files being committed into subversion, we use an svn filter that all developers have set within TortoiseSvn.

bin obj *\[Bb]in *\[Oo]bj */[Bb]in */[Oo]bj thumbs.db *.log *\aspnet_client *\core *\_ReSharper* *.resharper *.user *.suo *.scc *.vspscc *.vssscc *.gpState *.bak *.dat *.pdb *.sln.cache

And finally, here’s how our dev tree looks:

D:\dev\

D:\dev\branches\iteration032\

D:\dev\tags\

D:\dev\trunk\

\build (\build\compression)

\dist (\dist\sqlscripts, \dist\isapi)

\docs

\lib

\res (\res\images)  ** resources, for PSD’s etc…

\src (\src\website, \src\services, \src\shared)

\tools (\tools\nant, \tools\nunit, \tools\ncover)

I haven’t included every sub folder, but have given a few examples to give a rough idea. Within our “src” folder we have the “website” (and all related projects), “services” (for any WCF services) and “shared” (for any projects shared between applications).

Also, note the “build” folder. In this we keep all of our NAnt scripts, batch files for doing compressing etc… We don’t use it typically how something like Netbeans might, where “build” is the output of the compiled code.

This is an example of how our “\src\website” folder looks:

Huddle.Website

Huddle.Website.UnitTests

Huddle.Website.DataAccess

Huddle.Website.DataAccess.IntegrationTests

Huddle.Website.Model

Huddle.Website.Services

Huddle.Website.Services.UnitTests

etc…

Huddle.Website.sln

The next step is setting up the build and CruiseControl.Net, but more about that in another article.

Here are some of the articles I read/used during my research:

Leave a Reply