项目文件夹结构建议

Question

我准备实施一个源代码管理系统（颠覆），但我正面临着如何构建我的文件夹一些怀疑。

我使用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) 

符号 “ - ” 标记目录。

任何人都在意对当前结构发表评论或有任何改进建议吗？

谢谢！

Answer 1

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

如果您只使用IDE构建（编译和打包）您的项目，那么您可能只需遵循该IDE的典型约定以及任何可能找到的“最佳实践”。

但是，我强烈建议您不要仅使用IDE构建，甚至根本不要构建。相反，使用一个或多个可用的许多精彩的开源工具创建一个自动构建/发布脚本。既然你看起来是针对Windows的，我建议先看一下Ant，Ivy和相应的xUnit（jUnit for Java，nUnit for .NET等）来进行测试。

一旦你开始了这条道路，你会发现很多关于项目结构，设计你的构建脚本，测试等的建议。现在，我不会给你提供详细的建议，而只是给你留下这个建议 - 你很容易在那里找到你的问题的答案，以及找到更多值得调查的问题。

享受！

根据评论，似乎需要一些细节。

我会做的一个特别的建议是将代码库分成单独的子项目，每个子项目生成一个单一的可交付物。主要应用程序（.EXE）应该是一个，任何辅助二进制文件都将是单独的项目，安装程序将是一个单独的项目等。

每个项目都会生成一个主要可交付物：.EXE，.DLL，一个.HLP等等。这个可交付成果被“发布”到一个单独的，共享的，本地的输出目录。

制作一个目录树，其中的子项目是对等的（没有深度或层次结构，因为它没有帮助），也不要让项目“进入”彼此的子树 - 每个项目应该是完全独立的，在其他子项目的主要可交付成果中，在共享输出目录中引用。

不要创建相互调用的构建脚本的层次结构，我做了并发现它不会增加值，但会成倍增加维护工作量。相反，制作一个持续集成脚本来调用独立的构建脚本，但首先会对临时目录执行干净检查。

不要将任何可交付成果或依赖关系提交到源代码管理 - 不是您的构建输出，也不是您使用的库等。使用Ivy针对与源代码管理分开部署的类似Maven的二进制存储库，并发布您的将自己的交付成果交给您的组织进行共享。

呵呵，不要使用Maven - 它太复杂了，混淆了构建过程，因此不具有成本效益。

我正在朝着SCons，BuildBot，Ant，Ivy，nAnt等基于我的目标平台发展。

我一直在撰写关于这个话题的白皮书，我看到的可能有观众。

编辑：请看看我的详细解答How do you organize your version control repository?

Answer 2

为什么5.x？ （在项目A下）

我不认为在树中引入版本是有用的 - 这就是颠覆等等。