Organization of xLim solutions: development, svn and integration

In my last article for the xLim 2 series I've talked about some simple development principles that proved to be effective in the implementation projects. In this post I'll start describing the common solution structure that was established in that process.

Note, that I will not explicitly address database management in this structure (folder for the db-create, chained revision-based .cs and .sql upgrade scripts etc), since the XPO manages most part of the complexity here.

Below you will find the folder structure for the root of your version control repository.

SVN:

  Doc                   - development-related docs
    000 Global          - "Global" contains all
    001 Initialization    guidelines, MSP files,
    002 Project Planning  project scope/chapter etc
    003 Prototyping     - numbered folders form up
    004 Milestone 1.0.0   the simple timeline
    ...
  Extension             - extensions are kept and
    CRM                   managed separately. "System"
    E-Forms               distros go into "Resources"
    ConstructionPM        in a binary form
  System -->            - xLim framework
  Prototype             - those are better than UCs
    001 SimpleCAB         and represent excellent
    002 Web IoC           knowledge-base material
    003 DxGridSchema      for new developers.
    004 Workflows
    ...

Here's the generic organization of the "System" folder (that's the core sources for the specific xLim 2 implementation). The extension projects also have similar structure.

SVN:\System

  branch                - development branches, if needed
  distribute            - CC.NET releases into this folder
    1.0.0.23              X.Y.Z.Revision format
    1.0.1.45
    1.0.2.92
    ...
  tag
    1.0.0.1             - X.Y.Z.Revision format for every
    1.0.0.2               successful commit (autocreated
    1.0.0.3               by the integration server)
    ...
  trunk -->

Note, that it is a good idea to place some restrictions on the trunk folders from the very start (if you are using Subversion). Here are the switches that we normally setup:

• svn:ignore
• tsvn:logminsize (20-40 characters is enough)
• bugtraq:warnifnoissue
• bugtraq: logregex (it is enough to set "#(\d+)" pattern to make any #BugId number recognizable by both TortoiseSVN and Trac)
• bugtraq:url (for the purposes of trac integration this points to the tickets path and allows you to open referenced tickets by just clicking on the number in the TortoiseSVN log)

SVN:\System\trunk

  Help                 - help templates and articles
  Resource             - everything that's needed to build
    Dxperience           fresh check-out on a new machine
    Castle               is here (except .NET SDKs).
    EntLib               The same rule applies to the
    Images               specific extensions as well
    NAnt
    NUnit 
    7za.exe
  Source                    - that's just the sample. It
    xLim.Client.Core          will described below.
    xLim.Client.DxCore        
    xLim.Client.Interface       
    xLim.Client.Host          
    xLim.Server.Core         
    xLim.Server.Host
    xLim.Server.Interface
    xLim.Server.WebServices
    xLim.Shared.Business        
    xLim.Shared.Core
    xLim.Shared.Data
    xLim.Shared.Interface
    xLim.Web.Core
    xLim.Web.DxCore
    xLim.Web.Host
    xLim.Web.Interface
    GlobalAssemblyInfo.cs     - you keep those shared and
    VersionAssemblyInfo.cs      accessible, do not you?
  Test                        - unit tests per project
  Tool                        - some tools that could make
    DeploymentAid               development and maintenance
    NavigationBuilder           more simple and efficient
    SchemaTool
  xLim.Core.sln
  xLim.Core.build             - NAnt build file
  go.cmd                      - simply calls Resource/Nant
  Farmenu.ini                   for the build file

This is how the development checkout copy is usually organized for multiple solutions.

*Working folder (i.e.: E:\Projects\xLim): *

  Docs                        - check-out of the documents
  xLim.ConstructionPM         - check-out of the CPM trunk
  xLim.CRM
  xLim.System                 - check-out of the System trunk
    Build                     - this folder is autocreated

Here's the simple folder structure for the xLim 2 integration server.

Integration:

  Logs                        - rolling logs of CC.NET
  xLim.CPM                    - separate folder per solution
  xLim.CRM                      being built
  xLim.System
    Artifact                  - CC.NET build artifacts
    Build                     - NAnt works here 
    Distrib                   - integration server creates
      1.0.0.23                  distributions here and adds them
      1.0.1.45                  to the SVN. Normally "Distrib" 
      1.0.2.92                  is accessible via secure FTP
      ...                       
      lastversion.txt         - simple, but helps to automate
    State                     - CC.NET state information
    Trunk                     - Working copy
  ccnet.config                - the name speaks for itself

A word on the changes. The development cycle of the main project is separate from its extensions (that's convenient for medium-sized development projects and teams). Extensions use the "Interface" and "Core" libraries from the main xLim project (those are distributed in a form of packaged APIs and are stored in "Resources" folder in the binary form).

Additionally the integration server could package the extensions in one complete setup file along with the corresponding version of the actual application hosts (Server, Desktop or Web). That's where Integration:\xLim.System\Distrib[Version] are come in handy.

In my next post I'll concentrate on the logical structure and the internal dependencies of the actual "SVN:\System\trunk\" Visual Studio solution.

Comments

[Know thy dependencies and cont]

[...] there are more details on this atomic solution structure in the post on: Organization of xLim solutions: development, svn and integration Tags: autofac. [...]

[Continuous Integration for Pho]

[...] ensuring that the project structure conforms to some basic rules [...]

[Viagra]

I think the idea is good but you need to modify it a little.

[Debt]

Apologize for my bad english, I over its a winsome vent one's spleen of your writing. Kind-heartedly I have faced alot of difficulties in this train but your article discretion definately relieve me in future. Hold responsible You