项目文件夹结构推荐

Question

项目文件夹结构推荐

12

我准备实现一个源代码控制系统（Subversion），但我对如何组织我的文件夹存在一些疑问。

我使用Delphi进行所有的开发，并从IDE内部编译项目。

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

-E:\Work\1. Shared
--Forms（所有项目共享的窗体）
--Units（所有项目共享的单元/类，包括第三方库，如JCL）
-E:\Work\2. Company Name
--Admin（与管理工作相关的内容，如许可证密钥生成器、Windows CGI以自动处理订单处理等，均使用Delphi开发）
--Projects
----ProjectA
-----5.x（版本5.x）
------BIN（包含此项目所有二进制文件的目录）
------Build Manager（FinalBuilder项目所在的目录）
-------Install（创建安装程序setup.exe的NSIS文件）
-------Protection（保护已编译exe文件的项目文件）
-------Update（与自动更新相关的inf文件）
------Docs（包含readme.txt、license.txt和history.txt等在安装文件中的文本文件）
-------Defects（我或其他人测试时使用的文档）
-------HTMLHelp（项目的HTML帮助文件）
------R&D（包括屏幕截图、设计思路和其他研究和开发内容）
------Releases（使用FinalBuilder构建发布版时，由NSIS创建的安装程序文件将放置在此处）
------Resources（该项目使用的图像和其他资源）
------Source（如果存在子项目，则编译为BIN，因为它们都相关联）
-------SubprojectA
-------SubprojectB
-------SubprojectC
--Sites
--- companywebsite.com（目前唯一的一个网站，但如果我们决定为产品创建单独的网站，则所有网站将放置在Sites文件夹中）

减号“-”标记目录。

有人对当前结构进行评论或提出改进建议吗？

谢谢！

- smartins

2个回答

2

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

我认为在树形结构中引入版本号并不实用 - 这就是Subversion等工具的作用。

- Tim

5.x 指版本 5.x。我通常会为 1.x、2.x 等版本保留文件夹，以便快速访问旧版本。 - smartins

1

SVN会保留版本修订记录。它们应该在单独的标签/分支下（依我之见）。 - Tim

我理解，但是我还没有使用过SVN，所以这个文件夹结构目前是为非版本控制系统设置的。 - smartins

我发现将发布版本（如5.x）和修订版本分开非常有用。这对于在早期版本中重现错误时可以节省时间，将会是一个救星。 - Scottie T

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Rob Williams · Accepted Answer

我过去曾经设置过数百个项目，并且专门从事软件配置管理和发布工程方面的工作，因此我建议你首先关注如何构建/发布你的项目。

如果你仅使用集成开发环境（IDE）来构建（编译和打包）你的项目，那么你可能只需按照该IDE的典型约定以及任何你可能找到的“最佳实践”进行操作。

然而，我强烈建议你不要仅使用IDE或者干脆不要使用IDE进行构建。相反，使用许多优秀的开源工具之一创建自动化的构建/发布脚本。由于你似乎是针对Windows平台进行开发，所以我建议你先了解Ant、Ivy以及适用于测试的xUnit（Java的jUnit，.NET的nUnit等）。

一旦你开始这条路，你会发现有很多关于项目结构、设计构建脚本、测试等方面的建议。现在不会压倒你太多细节性建议，我只是留下这个建议——你可以很容易地找到这些问题的答案，同时也可以找到更多值得探究的问题。

祝好！

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

我特别推荐你将代码库拆分为单独的子项目，每个子项目都产生单个可交付成果物。主应用程序（.EXE）应该是一个子项目，任何支持二进制文件都应该是单独的子项目，安装程序也应该是单独的子项目等等。

每个项目都会产生一个主要成果物：.EXE、.DLL、.HLP等。该成果物“发布”到单个共享的本地输出目录中。

创建一个目录树，其中子项目是对等的（没有深度或层次结构，因为这并没有帮助），不要让项目“触及”到彼此的子树——每个项目应该完全独立，仅依赖于其他子项目的主要成果物，并引用共享输出目录中的这些成果物。

不要创建互相调用的构建脚本层级结构，我曾经这样做过，并发现它并没有增加价值，但会指数级增加维护工作的难度。相反，创建一个连续集成脚本，它可以调用你独立的构建脚本，但首先需要在临时目录中进行清理检查。

不要将任何可交付成果或依赖项提交到源代码控制中--不是你的构建输出，也不是你所使用的库等。使用Ivy连接类似Maven的二进制存储库，将其与源代码控制分开部署，并将自己的可交付成果发布到其中以供组织内共享。

哦，不要使用Maven--它太复杂了，会混淆构建过程，因此不利于定制。

根据我的目标平台，我正在转向SCons、BuildBot、Ant、Ivy、nAnt等构建工具。

我一直在撰写关于这个主题的白皮书，我认为它可能有受众。

编辑：请参见我对如何组织版本控制库？的详细回答。