Projects文件夹结构建议

我正准备实现一个源代码控制系统(颠覆),但我对如何构建我的文件夹面临一些疑问.

我使用Delphi进行所有开发,并在IDE中编译项目.

我当前的项目文件夹结构如下:

-E:\Work\1. Shared
--Forms (shared forms across all projects)
--Units (shared units/classes across all projects including 3rd party like JCL)

-E:\Work\2. Company Name
--Admin (stuff related with admin work like a license keys generator, Windows CGI to handle order processing automatically, all developed in Delphi)
--Projects
----ProjectA
-----5.x (version 5.x)
------BIN (where all the binaries for this project go)
------Build Manager (where the FinalBuilder project lives)
-------Install (NSIS file that create the setup.exe)
-------Protection (Project files to protect the compiled exe)
-------Update (inf files related with the auto-update)
------Docs (where the readme.txt, license.txt and history.txt that are included in the setup file are)
-------Defects (docs for any testing done by me or others)
-------HTMLHelp (html help for the project)
------R&D (where screenshots, design ideas and other R&D stuff goes to)
------Releases (when building a release with FinalBuilder the setup file created by nsis is placed here)
------Resources (Images and other resources used by this project)
------Source (if a sub-project exists it will compile to BIN since they are all related)
-------SubprojectA
-------SubprojectB
-------SubprojectC
--Sites
--- companywebsite.com (the only one at the moment but if we decide to have individual web sites for products they would all be placed on the Sites folder)

符号" - "标记目录.

有人关心对当前结构发表评论,还是有任何改进建议？

谢谢!

多年来设置了数百个项目,并专门从事软件配置管理和发布工程,我建议您首先关注如何构建/发布项目.

如果您只使用IDE来构建(编译和打包)您的项目,那么您可能只需遵循该IDE的典型约定,以及您可能找到的任何"最佳实践".

但是,我强烈建议您不要仅使用IDE构建,甚至根本不构建.相反,使用一个或多个可用的精彩开源工具创建自动构建/发布脚本.由于您似乎是针对Windows的,因此我建议首先查看Ant,Ivy以及相应的xUnit(适用于Java的jUnit,适用于.NET的nUnit等)以进行测试.

一旦你开始走这条道路,你会发现很多关于项目结构,设计你的构建脚本,测试等的建议.现在我不会给你提供详细的建议,我会简单地告诉你这个建议 - 你会很容易找到答案在那里你的问题,以及找到更多值得调查的问题.

请享用!

根据评论,似乎需要一些细节.

我要做的一个特别建议是,将您的代码库分成单独的子项目,每个子项目产生一个可交付成果.主应用程序(.EXE)应该是一个,任何支持二进制文件都是单独的项目,安装程序将是一个单独的项目,等等.

每个项目都会生成一个主要的可交付成果:.EXE,.DLL,.HLP等.该交付项被"发布"到单个共享的本地输出目录中.

创建一个目录树,其中子项目是对等的(没有深度或层次结构,因为它没有帮助),并且不要让项目"到达"彼此的子树 - 每个项目应该完全独立,仅依赖于主要可交付成果在共享输出目录中引用的其他子项目.

不要创建相互调用的构建脚本的层次结构,我做了,发现它不会增加价值,但会以指数方式增加维护工作量.相反,创建一个连续的集成脚本来调用您的独立构建脚本,但首先要清理结帐到临时目录.

不要犯任何交付或依赖到源代码控制 - 不是你生成的输出,而不是使用库等使用ivy对您部署从源头控制单独一个Maven般的二进制库,并发布自己的成果吧在您的组织内共享.

哦,不使用Maven - 实在是太复杂了,混淆了构建过程,因此不符合成本效益的定制.

我根据我的目标平台上向SCons,就BuildBot,蚂蚁,常春藤,楠等活动.

我一直在撰写关于这个主题的白皮书,我认为可能有观众.

编辑:请参阅我如何组织您的版本控制存储库的详细答案？