This is the next part in an ongoing series about setting up a continuous integration system. The series includes:

1. Part 1: Introduction
2. Part 2: Project Folders (this post)
   
3. Part 3: CI Workflow
4. Part 4: CI Server Baseline Software
5. Part 5: CruiseControl.NET Custom Plug-in: Update Version
6. Part 6: CruiseControl.NET Custom Plug-in: Source Retrieval
7. Part 7: Installing CruiseControl.NET and Custom Plug-ins
8. Part 8: Configuring CruiseControl.NET
9. Part 9: Conclusion

One of the fundamental aspects of a good continuous integration—even just a local dev environment—is the structure of your project folders. This is a fairly subjective topic as individuals or development groups each have their own philosophy. Here, and without further adieu, I present mine.

Software Development Folder Structure

* = does not get checked into source control

• <drive>: I default to the D drive if I have one. Otherwise, C.
  • archive: This is my project junkyard, for projects I no longer maintain or use, but which I can't quite bring myself to delete.
  • cc.net
    • config: CruiseControl.NET's config file(s) goes here.
  • doc: This is a good place for general software development documentation, best practices docs, or process and procedures sorts of documents. A copy of this post will likely wind up there.
    • images: Contains supporting images for docs found in the doc parent folder.
  • resources: These are resources that span multiple products/projects, like a company logo, for example. You might need or want more than just the sub-folders I currently have defined.
    • icons
    • images
  • sandbox: My development sandbox. This is the ultimate in junk drawers, where anything goes. I dump sample code here, as well as 'trial and error' types of projects. None of it is ever checked-in. If I do want to check something from here in, it gets moved into a solutions folders.
  • setup: This is an environment-wide area for any utilities, batch files, etc. I use to setup my development or build environments. The batch file (download below) that creates my initial folder structure lives here, for example.
  • solutions:
    • Widget (this is just a generic project name placeholder; rename as needed) This is where the .sln file lives. Individual projects then exist under the projects sub-folder.
      • backup: Sometimes I like to take zip file snapshots of my source, or I might have a version of some file that I want to hang on to separate from its source control location. Think of this as a generic project backup folder.
      • bin: This is where all build modules, debug and release, are emitted.
        • ccnet: This exists solely for CruiseControl.NET's benefit as I direct all cc.net output to the listed sub-folders.
          • artifacts: cc.net build artifacts.
            • buildlogs
              • debug
              • release
            • ncover: NCover files produced during cc.net's build.
        • WidgetControl
          • debug
          • release
        • WidgetService
          • debug
          • release
      • db: If there are any schemas (to create the database, for example) or stored procedures that go along with the project, they go here.
        • schema
        • sproc
      • deploy: If the project supports automatic deployment, especially as part of the CI environment, then any batch or script files needed for this process go here.
        • batch
        • scripts
      • doc: This is for project-specific documentation, such as technical or design specs, or usage guidelines.
        • images
      • imports: Any external assemblies the project consumes go here. By default, this typically includes such things as NUnit or log4net. I typically create sub-folders for each import, especially when there are two or more dll's to consider.
      • projects: The root folder for individual projects that live under this solution.
        • WidgetControl: Individual project files (.csproj, for ex.) as well as source files go here.
        • WidgetService
      • releases: As part of my CI environment I always zip up release candidate files (source + build modules) and put them here. Each zip is named with the appropriate cc.net determined version number.
      • test
        • artifacts: So far this winds up being a repository for any files my integration tests require. Not all projects have integration tests, so not all project use this folder
  • tools: This is where, broken down by sub-folder, every tool, gadget, utility, add-on, etc. that I use either for development or as part of my build environment, goes. This might include CruiseControl.NET, NUnit, ReSharper, etc. Basically any piece of software that I might need to download and install in order to restore my build environment or machine. There are varying philosophies on this approach:

Conclusion

That's my development folder structure. You can download the .bat file I use to create the initial structure (this is typically done only once), or tweak it as you see fit.

Next post in this series I'll be talking about continuous integration process workflow.

Download: MkProjFolders.zip