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.
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.
branch - development branches, if needed distribute - CC.NET releases into this folder 126.96.36.199 X.Y.Z.Revision format 188.8.131.52 184.108.40.206 ... tag 220.127.116.11 - X.Y.Z.Revision format for every 18.104.22.168 successful commit (autocreated 22.214.171.124 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:
- tsvn:logminsize (20-40 characters is enough)
- 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)
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.
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 126.96.36.199 distributions here and adds them 188.8.131.52 to the SVN. Normally "Distrib" 184.108.40.206 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.