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.